This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: --target=v850-unknown-elf, linker problem
- From: Erik Christiansen <erik at dd dot nec dot com dot au>
- To: Torsten Mohr <tmohr at s dot netic dot de>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 15 Aug 2005 18:08:06 +1000
- Subject: Re: --target=v850-unknown-elf, linker problem
- References: <200508142255.40310.tmohr@s.netic.de>
On Sun, Aug 14, 2005 at 10:55:40PM +0200, Torsten Mohr wrote:
> /opt/v850-unknown-elf/lib/gcc/v850-unknown-elf/3.4.4/v850e/libgcc.a \
> (_callt_save_interrupt.o): In function `__callt_return_interrupt':
> ../../gcc-3.4.4/gcc/config/v850/lib1funcs.asm:(.call_table_data+0x2): \
> relocation truncated to fit: R_V850_CALLT_16_16_OFFSET against `.text'
> collect2: ld gab 1 als Ende-Status zurück
To my untrained eye, this looks a little like a bug. In
v850/lib1funcs.asm, .L_return_interrupt should IMHO be in the
.call_table_text section, not .text. (Would you like to try making the
change? It's still line 1459 in 3.4.4) We might be able to sneak in a
fix before the experts arrive with more sage advice. ;-)
That said, using v850e-gcc 3.3, I found the easiest way to make all the
callt pain go away was to turn off compiler optimisation. (Although I
only have a fortnight's experience with the v850, so far it seems that
v850e-gcc 3.3 defaults to conventional push/pop sequences, in lieu of
the callt size optimisation. So there is no .call_table_data to
complicate initial attempts to get things to compile, if optimisation is
turned off. Version 3.4.4 may do the same.)
Adding your source lines to my first chunk of test code generated what was
expected:
00402000 <_irq_nmi>:
402000: 5c 1a add -4, sp
402002: 63 ef 01 00 st.w r29, 0[sp]
402006: 03 e8 mov sp, r29
402008: 1d 18 mov r29, sp
40200a: 23 ef 01 00 ld.w 0[sp],r29
40200e: 44 1a add 4, sp
402010: 7f 00 jmp [lp]
(And no errors. :-)
> When i don't use -mv850e, but use -mv850, all works fine.
IIUC that's because mv850 doesn't have the callt instruction, so the
problematic optimisation is not invoked.
I still don't fully grok the callt stuff either, so best of luck.
hth,
Erik