Re: Using linker script assignments in shared object

[Alan Modra <amodra at gmail dot com>]

On Wed, May 28, 2014 at 06:18:19PM +0400, Max Dmitrichenko wrote:
> 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.
> 
> So, is there any other way to pass some specified value to the code of
> shared object with the linker script?

You need to somehow stop the linker generating dynamic relocations for
locations where you use the symbol, and I don't think there is a way
to do that.  Now that *is* a ld bug, and perhaps I was wrong to blame
ld.so for your testcase because I'll bet the dynamic relocations
emitted don't even mention test_ls_value..  They'll be some sort of
RELATIVE reloc without a symbol.

However, fixing this in ld might prove difficult to do without
breaking many linker scripts.  For example, we define symbols like
"_end" outside of a section statement in the standard linker scripts,
which means they are absolute.  Yet clearly a symbol like "_end" is
really meant to be section relative, ie. its value ought to change
when you load a shared library at a different location than its
link-time address.

-- 
Alan Modra
Australia Development Lab, IBM