target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)
Richard Earnshaw
rearnsha@arm.com
Tue Mar 19 07:03:00 GMT 2002
> 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.
More information about the Gcc-bugs
mailing list