[PATCH 0/1] MIPS SDE-compatible bare metal target

Kevin Cernekee cernekee@gmail.com
Sun Sep 25 22:55:00 GMT 2011

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

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


For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list