This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Philip Blundell <pb at nexus dot co dot uk>
- Cc: Richard dot Earnshaw at arm dot com, gcc-gnats at gcc dot gnu dot org, pb at gcc dot gnu dot org, fnf at ninemoons dot com, gcc-bugs at gcc dot gnu dot org, rearnsha at gcc dot gnu dot org
- Date: Tue, 19 Mar 2002 15:09:54 +0000
- Subject: Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> I would be reluctant to have -shared imply PIC across the board. There
> are legitimate reasons why people might want to build a dynamic object
> but not pay the cost that goes with position independence. Perhaps this
> is a rare enough situation that it also isn't worth losing too much
> sleep over, I dunno. I must admit, having -shared generate PLT relocs
> by default for branches would go some way towards helping those people
> who accidentally link things like libiberty.a into their shared
> libraries.
It can't mean PIC across the board, since there is no way to alter the
code sequences that reference static data. The only solution will be
relocate the pages in question at load time. However, the dynamic relocs
for that aren't any different to the relocs for the GOT (except that they
relocate text pages rather than data pages, and thus prevent them from
being shared).
But for branches, my point still stands, the model to use for both types
of reloc is the same; and what's more, both cases would benefit from the
use of such a model (in one case it makes the code work when it wouldn't
have done otherwise, and in the second it makes the code more efficient by
eliminating the PLT stub when it isn't needed).
R.