newlib does not pick up the right cross-compiling gcc

Josef Wolf jw@raven.inka.de
Mon Feb 8 12:50:00 GMT 2010


On Mon, Feb 08, 2010 at 11:34:26AM +0100, Josef Wolf wrote:
> On Sat, Feb 06, 2010 at 09:11:15PM +0100, Josef Wolf wrote:
> > Without the --enable-targets option, I can build the current versions of the
> > toolchain: binutils-2.20, gcc-4.4.3 and newlib-1.18.0. I have not checked
> > (yet) whether the code that this toolchain generates actually works, though.
> 
> I've checked now, and see it failing. Looks like the linker fetches wrong
> version of the newlib (coldfire, maybe?)
> 
> I see this code for the strchr() function in my emulator:
> 
>  link.w a6,#$0
>  movem.l d2-d4,-(a7)
>  move.l ($c,a6),d1
>  move.l ($8,a6),d0
>  move.b d1,d2
>  beq.w $35040
>  dc.w $e8c0               ; this line crashes the processor
>  bclr d3,d2
>  [ ... ]

The -msoft-float option was responsible to generate the illegal instructions.
I find that somewhat confusing: why does strchr() need floating point
operations? And why do they generate illegal instructions?

Now that this is solved, it crashes in printf(). Any hints how to track this
down?

One more problem: although I compile/link with -g, objcopy tells me that no
debugging information is available:

 m68k-unknown-elf-gcc -ansi -pedantic -Wall -Wcast-align -Wstrict-prototypes \
    -Wmissing-prototypes -std=c89 -O2 -m68332 -msoft-float -c -o hello.o hello.c
 m68k-unknown-elf-gcc -nostartfiles -Wl,--cref -Wl,-Ttext=0,--entry=entry \
    -Wl,--oformat,elf32-m68k -Wl,--cref,-Map,hello.map \
    -Wl,-T,ldscript -ansi -pedantic -Wall -Wcast-align \
    -Wstrict-prototypes -Wmissing-prototypes -std=c89   -O2  -m68332 \
    -o hello.elf hello.o -lc
 m68k-unknown-elf-objcopy -O ieee --debugging hello.elf hello.ieee
 m68k-unknown-elf-objcopy: hello.elf: no recognized debugging information



More information about the Newlib mailing list