Re: linker crash in arm stub generation

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jun 15, 2009 at 04:20:52PM +0200, Christophe LYON wrote:
> Hi,
>
>>> This looks good to me - and I agree that a test would be helpful!
>>>
>> I'll propose one + proper ChangeLog entry next week.
>>
>
> I have started to look at this problem more closely, and I have one  
> question: in elf32-arm.c:allocate_dynrelocs(), there is this comment:
>
>   /* If this symbol is not defined in a regular file, and we are
>      not generating a shared library, then set the symbol to this
>      location in the .plt.  This is required to make function
>      pointers compare as equal between the normal executable and
>      the shared library.  */
>
> Why is the behaviour different when generating a shared lib?
>
> I thought I had understood the comment about function pointers  
> comparison, but I am wondering now....

A PLT entry with a non-zero address is used as the canonical location
of the function.  This is only ever required in an executable, never
in a shared library.  If all accesses to the address are PIC - which
they must be, in a shared library - then they can be easily adjusted
to point to the function's address.  And it's better to do that,
because calls through those pointers will go directly to the function
instead of to the PLT.

In an executable, this might not be the case.  For instance you might
have the address of the funtion in a constant pool in the text
segment.  If that happens, the linker must fix the address of the
function at static link time, even if the definition turns out to be
in a shared library.

Such code is (or is supposed to be, anyway) rejected in shared
objects.

-- 
Daniel Jacobowitz
CodeSourcery