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

[Richard Earnshaw <rearnsha@arm.com>]

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

From: Richard Earnshaw <rearnsha@arm.com>
To: Philip Blundell <pb@nexus.co.uk>
Cc: Richard.Earnshaw@arm.com, 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: Tue, 19 Mar 2002 14:53:23 +0000

 > On Tue, 2002-03-19 at 11:55, Richard Earnshaw wrote:
 > > OK, so that clears up that side of the problem.  Now, what about the issue 
 > > that PLT32 and ARM24 aren't really different relocs?
 > 
 > Well, that depends on your point of view.
 > 
 > Obviously they are the same in terms of the fundamental bit operations
 > that they perform on the instruction.  But the PLT32 reloc has some
 > extra semantics stacked on top: if the symbol isn't known to be local,
 > it generates a plt entry and redirects the branch through it.
 
 I realise that, however I don't think that in reality this is any 
 different from the semantics required for PC24.
 
 > You could more or less dispose of the issue by adding an option to the
 > linker to say you wanted to generate a PIC executable.
 
 There are four cases I believe we need to consider:
 
 1) Putting non-PIC code into the static part of a program (normal case)
 2) Putting PIC code into a shared library (normal shared-library case)
 3) Putting PIC code into the static part of a program
 4) Putting non-PIC code into a (shared) library.
 
 It is understood that 3 and 4 may not result in the most efficient code; 
 in particular case 4 may mean that code pages cannot be shared (since they 
 are no-longer position independent and may need relocating at load time).  
 But they are required to execute correctly.
 
 >  If that was set,
 > you would treat all PC24 relocs like PLT32s are now; if not, you would
 > treat them as straight PC24.  I think the situation where someone is
 > deliberately mixing PIC and PDC objects in order to get a hybrid output
 > file is rare enough that it can be neglected.  On the other hand, people
 > are accustomed to controlling this with -fPIC at the compilation stage,
 > and changing it to be a linker option might turn out to be a nightmare.
 
 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.
 
 R.