[dtrace-discuss] What are .dynstr dtrace strings and why they change?
Alexander Kolbasov
akolb at eng.sun.com
Tue Oct 2 21:11:29 PDT 2007
Ali Bahrami <Ali.Bahrami at Sun.COM> wrote:
Ali> I'm betting that these are local symbols referenced by the .SUNW_ldynsym
Ali> section, which is an allocable section, and therefore uses the
Ali> dynstr:
Are these randomly generated during each build or they are
deterministic? Does it mean that wsdiff will always pick these up as a
change in libc?
- Akolb
Ali> ali at rtld% elfdump -sN.SUNW_ldynsym /lib/libc.so | grep dtrace
Ali> [12] 0x000a7202 0x0000038f FUNC LOCL H 0 .text $dtrace9391.
Ali> [66] 0x000a6360 0x00000260 FUNC LOCL H 0 .text $dtrace9391.
Ali> [134] 0x000a7a30 0x0000024d FUNC LOCL H 0 .text $dtrace9391.
Ali> [349] 0x000a6a50 0x00000139 FUNC LOCL H 0 .text $dtrace9391.
Ali> [368] 0x000a6b90 0x00000111 FUNC LOCL H 0 .text $dtrace9391.
Ali> [473] 0x000a5e40 0x000001ed FUNC LOCL H 0 .text $dtrace9391.
Ali> [601] 0x000a6ff0 0x00000073 FUNC LOCL H 0 .text $dtrace9391.
Ali> [655] 0x000a6646 0x0000026a FUNC LOCL H 0 .text $dtrace9391.
Ali> [684] 0x000a76d0 0x00000172 FUNC LOCL H 0 .text $dtrace9391.
Ali> [762] 0x00000000 0x00000000 FILE LOCL D 0 ABS dtrace_data.
Ali> .SUNW_ldynsym lets us report names for static functions instead of hex addresses
Ali> when looking at stripped objects. For example, 'pstack' uses this, via libproc.
Ali> For more about this:
Ali> PSARC 2006/526 SHT_SUNW_LDYNSYM - default local symbol addition
Ali> 4934427 runtime linker should load up static symbol names visible to dladdr()
>>
>> Once the following bug is putback, it will be possible for DTrace to mark
>> these temporary symbols so that they don't show up in the final binary at
>> all:
>>
>> 6602451 new symbol visibilities required: EXPORTED, SINGLETON and ELIMINATE
>>
Ali> I believe Rod filed the RTI for this today, so we're getting close.
Ali> - Ali
More information about the dtrace-discuss
mailing list