This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Using linker script assignments in shared object
- From: Max Dmitrichenko <dmitrmax at gmail dot com>
- To: Max Dmitrichenko <dmitrmax at gmail dot com>, binutils at sourceware dot org
- Date: Wed, 28 May 2014 18:18:19 +0400
- Subject: Re: Using linker script assignments in shared object
- Authentication-results: sourceware.org; auth=none
- References: <CAMRqRqyTbGY60374hnVoc6PhLkWDNNd-1K2WwQ1WS=DFDMPtmQ at mail dot gmail dot com> <20140528141152 dot GI6679 at bubble dot grove dot modra dot org>
Alan, thanks for the quick answer. I've googled around an hour to find
an answer but never thought that issue was so deep.
So, is there any other way to pass some specified value to the code of
shared object with the linker script?
2014-05-28 18:11 GMT+04:00 Alan Modra <amodra@gmail.com>:
> On Wed, May 28, 2014 at 05:29:26PM +0400, Max Dmitrichenko wrote:
>> But when I paste this code into shared object then I got some address
>> in the middle of memory address space. Though readelf outputs
>> following for this symbol:
>>
>> 552: 0000000000000005 0 NOTYPE LOCAL HIDDEN ABS test_ls_value
>
> This isn't a problem with ld, but with the dynamic loader ld.so.
>
> ld.so shouldn't relocate absolute symbols but does, because some
> ancient linkers made symbols like _GLOBAL_OFFSET_TABLE_ absolute, and
> GNU ld followed this bad practise. It's not impossible to fix in a
> way that keeps backward compatibility (eg. bump EI_ABIVERSION to
> indicate to ld.so that absolute symbols really are absolute), but no
> one has cared enough to do the glibc and ld work required.
>
> --
> Alan Modra
> Australia Development Lab, IBM