Martin Man wrote:

I'm just curious why this happens, what these symbols mean, and what are they used for. Seems that GNU ld is picking them up in situations where it shouldn't be, and I would like to reproduce a test case where ld can deliberately exhibit this bug.
...
P.S. an excerpt of
$ nm -D libc.so | grep '00000000 A'
...
00000000 A dladdr
00000000 A dladdr1

These are filters.  For a long time we have produced shared objects that
act as filters on other shared objects.  The whole object has acted as
a filter:

oxpoly 490. elfdump -d /usr/lib/libdl.so.1 | fgrep FILTER
       [1]  FILTER            0xe6                /usr/lib/ld.so.1
oxpoly 491. elfdump -d /usr/lib/libsys.so.1 | fgrep FILTER
       [1]  FILTER            0x758               /usr/lib/libc.so.1

In Solaris 10, we added per-symbol filtering, a mechanism where
individual symbols could be identified as filters.  In fact this
got back ported to Solaris 9 9/04.  See:

http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl1q?a=view

The filtering is triggered because we maintain an auxiliary array
of information for the symbol table - the SHT_SUNW_syminfo,
.SUNW_syminfo section.  You can dump this with:

oxpoly 493. elfdump -y /lib/libc.so.1 | grep dladdr
    [1176]  F            [1] /usr/lib/ld.so.1         dladdr1
    [1291]  F            [1] /usr/lib/ld.so.1         dladdr
    [1641]  F            [1] /usr/lib/ld.so.1         _dladdr1
    [1913]  F            [1] /usr/lib/ld.so.1         _dladdr
            ^
       SYMINFO_FLG_FILTER

When ld(1) resolves an object to a filter symbol, it simply creates
the appropriate reference.  For function references, this would be the
creation of a procedure linkage table entry, .plt:

oxpoly 498. elfdump -sN.dynsym /lib/libc.so.1 | grep dlopen
    [2328]  0x00000000 0x00000000  FUNC GLOB  D    5 ABS            dlopen
oxpoly 499. cc -o main main.c
oxpoly 500. elfdump -r main | fgrep dlopen
  R_SPARC_JMP_SLOT            0x20ca4          0  .rela.plt      dlopen

When the runtime linker binds the process, it redirects the binding
to the filtee.  In this case, the call is resolved to ld.so.1 itself.
Because of this redirection, there is no need for any code to back the
filter symbol definition - hence it is defined as ABS.

Another form of filtering is auxiliary filtering, this redirects the
binding at runtime if a "better" implementation exists, but if not
falls back to the original library:

oxpoly 503. elfdump -y /lib/libc.so.1 | grep memcpy
      [93]  A            [2] /platform/$PLATFORM/lib/libc_psr.so.1 memcpy

As this function has backing code, the symbol defines the associated
code:

oxpoly 504. elfdump -sN.dynsym /lib/libc.so.1 | fgrep memcpy
      [93]  0x0003fed0 0x000001b0  FUNC WEAK  D   38 .text          memcpy
     [583]  0x0003fed0 0x000001b0  FUNC GLOB  D   36 .text          _memcpy


With the introduction of per-symbol filters, we were able to simplify
and refine many object filtering mechanisms.  For example, the dl*
family could be defined in libc (you don't need to link with -ldl
anymore).


Send me mail if you need more information.


--

Rod.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to