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