This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I ran into a couple of semi-obscure issues linking objects generated from the mips-unknown-elf sample toolchain into a program built with Sourcery G++ (now Sourcery CodeBench), and I wanted to pitch the idea of including an SDE-compatible sample config in the release. I have not performed enough testing to be confident that I know about all of the changes needed for 100% SDE compatibility, but maybe this will get the ball rolling and somebody more knowledgeable can help fill in the gaps... Problem #1: mips-unknown-elf uses SGI-compatible symbol ordering: $ nm -ap _fixunssfsi-sgi.o | nl | tail -n 6 18 00000000 a /big/ct/sgi/.build/src/gcc-4.4.6/libgcc/../gcc/libgcc2.c 19 U __gesf2 20 U __subsf3 21 U __fixsfsi 22 00000000 T __fixunssfsi 23 00000000 r $LC0 In SGI mode, sh_info in the symtab's section header entry points to line 18. By contrast, a copy of binutils that had been built as an SDE or Linux toolchain assumes that sh_info points to the first global symbol, and that all local symbols (such as $LC0) have an index lower than sh_info (in this case, 20): $ nm -ap _fixunssfsi.o | nl | tail -n 9 15 00000000 r $LC0 16 00000000 r .reginfo 17 00000000 n .pdr 18 00000000 n .comment 19 00000000 n .gnu.attributes 20 U __gesf2 21 U __subsf3 22 U __fixsfsi 23 00000000 T __fixunssfsi A non-SGI ld may report the former case as a malformed object file: mipsel-linux-ld: error: _fixunssfsi-sgi.o contains a reloc (0x0000000000001705) for section .text that references a non-existent global symbol mipsel-linux-ld: final link failed: Bad value Fix: use "sde" instead of "unknown" for CT_TARGET_VENDOR. If the tuple is mips-sde-elf, binutils will disable the SGI/IRIX quirks. Problem #2: In my test runs, CT_CC_GCC_ENABLE_TARGET_OPTSPACE caused libgcc to be built with the MIPS SDA data model. i.e. it assumes that $gp always points to a "small data area" which can access items in the .sdata and .sbss sections using just a signed 16-bit offset. Many embedded programs do use SDA, but some do not and this could cause incompatibilities. Fix: disable CT_CC_GCC_ENABLE_TARGET_OPTSPACE -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |