From: Kevin Cernekee <cernekee@gmail.com>
To: <yann.morin.1998@anciens.enib.fr>
Cc: <crossgcc@sourceware.org>
Subject: [PATCH 0/1] MIPS SDE-compatible bare metal target
Date: Sun, 25 Sep 2011 22:55:00 -0000 [thread overview]
Message-ID: <6a090cb065f7e04df21964252f31657c@localhost> (raw)
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
next reply other threads:[~2011-09-25 22:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-25 22:55 Kevin Cernekee [this message]
2011-09-25 22:55 ` [PATCH 1/1] samples: add new mipsel-sde-elf sample Kevin Cernekee
2011-09-27 17:53 ` Yann E. MORIN
2011-09-27 18:23 ` Yann E. MORIN
2011-09-27 17:52 ` [PATCH 0/1] MIPS SDE-compatible bare metal target Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a090cb065f7e04df21964252f31657c@localhost \
--to=cernekee@gmail.com \
--cc=crossgcc@sourceware.org \
--cc=yann.morin.1998@anciens.enib.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).