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: Philip Blundell <pb at nexus dot co dot uk>
- To: Richard dot Earnshaw at arm dot com
- Cc: 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: 19 Mar 2002 15:02:04 +0000
- Subject: Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)
- References: <200203191453.OAA19876@cam-mail2.cambridge.arm.com>
On Tue, 2002-03-19 at 14:53, Richard Earnshaw wrote:
> Given the above, my assertion is that the rules for PLT32 and PC24 are now
> the same, and that these aren't distinct relocations at all -- if we are
> putting the code into a shared library, then we must indirect through a
> PLT stub unless we know the function to be local (and static). If we
> aren't (generating a shared library) then we need only indirect through
> such a stub if we need to access another module. The linker already knows
> whether it is producing a shared library or not, so this isn't adding
> anything new.
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.
p.