Re: [gentoo-embedded] Crossdev and arm-none-eabi and armv7m-none-eabi toolchain builds.

[Markos Chandras]

On Fri, Nov 2, 2012 at 4:19 AM, "Pablo Pölcher" <talosds@×××.de> wrote:
> Hello,
>
> this is my first post in this list, so please forgive any mistakes I may be doing here.
>
> I have been recently trying to compile a toolchain for the NXP LPC17xx
> microcontroller series using crossdev and came across a series of
> problems, which I have solved to a certain extent and wanted to share them in case somebody is interested.
>
> The CHOST I was trying to (and could finally) build for is «armv7m-none-eabi» (by running crossdev -t armv7m-none-eabi -s4 --ex-gdb). The main problem I encountered is that I couldn't get a stage1 gcc built. The build log would always end with the error message:
>
> «configure: error: cannot compute suffix of object files: cannot compile»
>
> After poking among the different log files, I found out that the problem
> was that the compiler was being asked to generate ARM code for a Thumb-only microcontroller, to what gcc would simply exit with the error code:
>
> «Error: Target CPU does not support ARM mode»
>
> So I traced back the generation of the argument list for the configure script back to toolchain.eclass, wrote a little patch and bingo! I could get past the annoying error. I just checked for the architecture to be armv7-m and added the --with-mode=thumb switch. There's an additional case to consider, and that is the armv6m architectures, but since I haven't tried them, yet, I haven't tested it nor included them in my patch.
>
> Anyway, once I got through this first problem, I had trouble again while compiling the stage3 gcc. Poking around a bit more, I found out that if the openmp USE flag is set, the gcc ebuild will try to build libgomp, even if no support for pthreads is present (as is the case with my newlib-based toolchain), so I could get around by disabling openmp during crossdev execution, but I guess this could also go as a toolchain.eclass patch.
>
> One more thing is that I couldn't see any place where the use of the multilib USE flag is recommended when compiling newlib, but still I found
> it useful.
>
> And one last thing I noticed (but couldn't get to solve, yet) is that I could never get crossdev to generate thumb code when compiling newlib for the «arm-none-eabi» CHOST, even if I pass the multilib USE flag. I tried tweaking several things, but I guess I should take a longer while to trace
> the error (feature?) and fix it. The crt0.o in /usr/arm-none-eabi/lib/thumb/ looks like this:
>
> 00000000 <_mainCRTStartup>:
>    0:        e3b00016         movs        r0, #22
>    4:        e28f10e8         add        r1, pc, #232        ; 0xe8
>    8:        ef123456         svc        0x00123456
>    c:        e59f00e0         ldr        r0, [pc, #224]        ; f4 <change_back+0x4>
>   10:        e5901000         ldr        r1, [r0]
>   14:        e3510000         cmp        r1, #0
> ...
>
> As you can see, it's ARM code. The armv7m-none-eabi version of crt0.o in
> the thumb directory looks like:
>
> 00000000 <_mainCRTStartup>:
>    0:        2016              movs        r0, #22
>    2:        a12d              add        r1, pc, #180        ; (adr r1, b8 <_mainCRTStartup+0xb8>)
>    4:        beab              bkpt        0x00ab
>    6:        482c              ldr        r0, [pc, #176]        ; (b8 <_mainCRTStartup+0xb8>)
>    8:        6801              ldr        r1, [r0, #0]
>    a:        2900              cmp        r1, #0
>
> Nice Thumb code. I found out this while pulling my hair off trying to find out why my nicely compiled code would throw a double hardfault on an LPC1765. I was using the arm-none-eabi toolchain, then. Once I switched to
> the armv7m one, everything was solved.
>
> Anyway, I hope this helps somebody somehow, and I'm sorry if you already
> knew about all this.
>
> Best regards,
> Pablo Pölcher

Hi Pablo,

I'd say that patches for portage eclasses should be attached on
bugzilla[1] as a new bug

[1]: https://bugs.gentoo.org

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2