-------- Original-Nachricht -------- > Datum: Fri, 2 Nov 2012 12:13:45 +0000 > Von: Markos Chandras <[email protected]> > An: [email protected] > Betreff: Re: [gentoo-embedded] Crossdev and arm-none-eabi and > armv7m-none-eabi toolchain builds.
> On Fri, Nov 2, 2012 at 4:19 AM, "Pablo Pölcher" <[email protected]> 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 > Thank you, I'll do that. Pablo
