Re: [osol-discuss] shared library symbols at address 0x00000000

[Martin Man <Martin dot Man at Sun dot COM>]

Hi Rod,

[ CCing binutils list because this explanation might be useful for 
developers there to see where GNU ld stands regarding the filter symbols ]

Rod Evans wrote:
> Some more information - perhaps examples would be better.
>
> Here is a traditional dlopen() example.  Note, the caller
> establishes a .plt, and a reference to libdl.  libdl is an
> object filter that causes redirection to ld.so.1 at
> runtime.

ok,

> oxpoly 406. cat > xxx.c
> #include <dlfcn.h>
> void main()
> {
>         dlopen("foo.so.1", RTLD_LOCAL);
> }
> oxpoly 407. elfdump -N.dynsym -s /lib/libdl.so.1 | fgrep dlopen
>        [1]  0x00000000 0x00000000  FUNC GLOB  D    9 ABS            dlopen
> oxpoly 408. elfdump -d /lib/libdl.so.1 | fgrep FILTER
>        [1]  FILTER            0xe6                /usr/lib/ld.so.1
> oxpoly 409. cc -o xxx1 xxx.c -ldl
> oxpoly 411. elfdump -N.dynsym -s xxx1 | fgrep dlopen
>        [3]  0x00020cd8 0x00000000  FUNC GLOB  D    0 UNDEF          dlopen
> oxpoly 412. elfdump -r xxx1 | fgrep dlopen
>        R_SPARC_JMP_SLOT          0x20cd8           0 .rela.plt      dlopen
>
> Note, the caller has no ABS symbol, only the destination does.  But in
> effect the ABS is irrelevant, as the caller doesn't bind to the destination
> at runtime, the caller binds to ld.so.1 through the filtering mechanism.

I don't understand what is the use of filtering mechanism here, if I 
explicitly stated that xxx1 will be linked against -ldl

> With per-symbol filters, we have a similar scenario:
>
> oxpoly 413. elfdump -N.dynsym -s /lib/libc.so.1 | fgrep dlopen
>     [2328]  0x00000000 0x00000000  FUNC GLOB  D    5 ABS            dlopen
> oxpoly 414. elfdump -d /lib/libc.so.1 | fgrep FILTER
>        [1]  SUNW_FILTER       0xb35c              /usr/lib/ld.so.1
> oxpoly 415. elfdump -y /lib/libc.so.1 | fgrep dlopen
>     [2328]  F            [1] /usr/lib/ld.so.1         dlopen
> oxpoly 417. elfdump -N.dynsym -s xxx2 | fgrep dlopen
>        [3]  0x00020ca0 0x00000000  FUNC GLOB  D    0 UNDEF          dlopen
> oxpoly 418. elfdump -r xxx2 | fgrep dlopen
>        R_SPARC_JMP_SLOT          0x20ca0           0 .rela.plt      dlopen
>
> Again, the caller makes the same reference.  However, this time the
> implementation also acts as a filter, but only for those symbols explicitly
> tagged to be filters.

I can't find in the example above how was the xxx2 compiled/linked. I 
suppose you omitted -ldl, in which case libc defined dlopen was used to 
filter calls to dlopen through /usr/lib/ld.so.1

> So, if I read your bug reports correctly, you might have a couple of
> issues:
>
>  i.    the linker is propagating the ABS index to the caller, and in
>     so doing invalidating the callers reference, and/or

yes, this is my probable cause with GNU ld

>  ii.    you have an environment where you runtime linker does not
>     understand the SUNW_FILTER/SYMINFO_FLG_FILTER implementation,
>     and thus binds the call to the ABS symbol expecting some
>     implementation code to back it.

yes, I suppose this is the root cause of (i), and I'm trying to seek 
some additional information.

As a side note. Could you elaborate more about where is per-library and 
per-symbol filtering useful, what is it used for, and what are the 
drawbacks of it? I have read the Solaris Linker and Libraries Guide and 
seem to have identified that it is used to

"abstract compilation environment from the run-time environment"

which sounds nice, but makes (so far) not much sense to me. Is it 
something related to binary compatibility?

thanx for your time,
Martin

--
http://martinman.net