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

[Richard Earnshaw <rearnsha at arm dot com>]

> 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.