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

Martin Man Martin.Man@Sun.COM
Tue Nov 21 16:41:00 GMT 2006

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.


> 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,


More information about the Binutils mailing list