Re: Why do I have "UNKNOWN" relocs in my v850 crt*.o?

[Bernd Jendrissek <berndj at prism dot co dot za>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Sorry, the threading will be screwed up on this message.]

>On Wed, Mar 24, 2004 at 04:32:41PM +0200, Bernd Jendrissek wrote:
>> Then, the other day, I was overjoyed to see that both binutils and GCC
>> supported v850, the processor the VeriFone SC5000 pinpad uses.  I now
>> seem to have a toolchain that wants to work, but...
>>
>> $ Reading specs from /usr/cross/lib/gcc-lib/v850/3.3.3/specs
>> v850-gcc: unrecognized option `-nostdlibs'
>> Configured with: /usr/src/home/rpmtest/tmp/BUILD/gcc-3.3.1/configure --srcdir=/usr/src/home/rpmtest/tmp/BUILD/gcc-3.3.1 --prefix=/usr/cross --mandir=/usr/cross/v850/man --infodir=/usr/cross/v850/info --target=v850 --with-gcc --with-as=/usr/cross/bin/v850-as --with-ld=/usr/cross/bin/v850-ld --with-slibdir=/lib --with-gxx-include-dir=/usr/cross/v850/mingw32/include/g++-v3 --without-x --disable-nls --disable-shared --enable-threads --enable-languages=c --enable-libgcj --disable-java-awt --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-sjlj-exceptions --with-dwarf3 --with-system-zlib
>        
>Try --target=v850-elf instead?

Will try that... later, but thanks.

>> Thread model: single
>> gcc version 3.3.3
>>  /usr/cross/bin/v850-ld -o foo -L ../../../SDK/Lib -L/usr/cross/lib/gcc-lib/v850/3.3.3 -L/usr/cross/lib/gcc-lib/v850/3.3.3/../../ ../../v850/lib ../../../SDK/Lib/crtPulsarPlus.o ../../../SDK/Lib/crt0.o AppMain.o -lgcc -lc -lgcc
>> /usr/cross/bin/v850-ld: ../../../SDK/Lib/crtPulsarPlus.o: Relocations in generic ELF (EM: 36)
>> ../../../SDK/Lib/crtPulsarPlus.o: could not read symbols: File in wrong format
>
>How did you configure binutils?  It doesn't look right.

"It" doesn't look right - what?

In my RPM spec file I have

./configure --prefix=%{_prefix}/cross --localstatedir=/var --target=v850 --enable-targets=all --enable-shared --enable-64-bit-bfd

I have --enable-targets=all lib{bfd,opcodes}.so in /usr/lib, against
which these cross tools are linked.

(I tried that linker command again with EM_V800's changed to EM_V850's,
and now the linker segfaults.  Hmm, needs investigation...)

>> $ objdump -b elf32-v850 -m v850 -r ../../../SDK/Lib/crtPulsarPlus.o
>
>Use readelf, or use v850-objdump.

Yes, I do that too, with the same result.

*BIG CLUE*: when I hex-edit the machine type in the ELF header, from
0x36 (NEC V800) to 0x57 (NEC V850), it suddenly seems to make sense:

$ objdump -b elf32-v850 -m v850 -r crtPulsarPlus.o

crtPulsarPlus.o:     file format elf32-v850

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
000000ba R_V850_CALLT_16_16_OFFSET  .text+0x000000be
000000d0 R_V850_CALLT_16_16_OFFSET  ___dotsyscall
000000d6 R_V850_16         ___ghsbegin_rosdata
000000da R_V850_8          ___ghsbegin_rosdata
000000f2 R_V850_16         __ep
000000f6 R_V850_8          __ep
000000fe R_V850_REL32      .text+0x000000be
000000fe R_V850_GNU_VTENTRY  ___callt_table
00000102 R_V850_REL32      .text+0x000000be
00000102 R_V850_LONGCALL   ___callt_table
00000118 R_V850_REL32      .text+0x000000be
00000118 R_V850_GNU_VTENTRY  .text+0x000001dc
0000011c R_V850_REL32      .text+0x000000be
0000011c R_V850_LONGCALL   .text+0x000001dc
00000120 R_V850_CALLT_16_16_OFFSET  ___ghs_ind_crt0
000001dc R_V850_9_PCREL    ___ghsbegin_picbase
000001e0 R_V850_9_PCREL    ___ghsbegin_robase
000001e4 R_V850_9_PCREL    ___ghsbegin_pidbase

Hey, is it possible that the very reason I need to give objdump the -b
and -m options is because the file is elf32-v800 (as yet unsupported)
and not elf32-v850?  AFAIK the V850 is part of the "V800 series", so I
would hope getting binutils to work with Green Hills output would be as
easy as teaching bfd to consider v850 as just a special case of v800.

(Hmm, I don't want to attach the object file or its disassembly due to
copyright concerns - better ask me for details and I'll exercise some
fair use (does reverse engineering count?) rights.)

TIA & HAND

- -- 
I've generally found that the fastest way to get the right answer on the net
is to confidently assert the answer you believe to be right; those who know
will immediately correct you, while if you just ask, often no answers arrive.
All it requires is a willingness to look bad on occasion.
                                               - Joe Buck on gcc@gcc.gnu.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAaEuW/FmLrNfLpjMRAhlqAJ9Co6lxH00TqjGbDDwt/vdoDF2bYwCdFxwB
QOAXn//0EFowBKNNn8XNqVk=
=sZEO
-----END PGP SIGNATURE-----