Mailing List Archive

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