Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)

[Philip Blundell <pb@nexus.co.uk>]

The following reply was made to PR target/3925; it has been noted by GNATS.

From: Philip Blundell <pb@nexus.co.uk>
To: Richard.Earnshaw@arm.com
Cc: gcc-gnats@gcc.gnu.org, pb@gcc.gnu.org, fnf@ninemoons.com, 
	gcc-bugs@gcc.gnu.org, rearnsha@gcc.gnu.org
Subject: Re: target/3925: [ARM/Thumb] Assembler chokes on branches with 
	(PLT)
Date: 19 Mar 2002 15:02:04 +0000

 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.