Ali Bahrami <[EMAIL PROTECTED]> 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> [EMAIL PROTECTED] 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
_______________________________________________
dtrace-discuss mailing list
[email protected]
