Adam Leventhal wrote:
> If you have USDT probes in static functions, the dtrace -G invocation will
> generate these symbols. They be should be scoped local in the final binary
> (I'm surprised that they're showing up in the dynstr -- that's probably a
> bug in the linker).
I'm betting that these are local symbols referenced by the .SUNW_ldynsym
section, which is an allocable section, and therefore uses the dynstr:
[EMAIL PROTECTED] elfdump -sN.SUNW_ldynsym /lib/libc.so | grep dtrace
[12] 0x000a7202 0x0000038f FUNC LOCL H 0 .text
$dtrace9391.
[66] 0x000a6360 0x00000260 FUNC LOCL H 0 .text
$dtrace9391.
[134] 0x000a7a30 0x0000024d FUNC LOCL H 0 .text
$dtrace9391.
[349] 0x000a6a50 0x00000139 FUNC LOCL H 0 .text
$dtrace9391.
[368] 0x000a6b90 0x00000111 FUNC LOCL H 0 .text
$dtrace9391.
[473] 0x000a5e40 0x000001ed FUNC LOCL H 0 .text
$dtrace9391.
[601] 0x000a6ff0 0x00000073 FUNC LOCL H 0 .text
$dtrace9391.
[655] 0x000a6646 0x0000026a FUNC LOCL H 0 .text
$dtrace9391.
[684] 0x000a76d0 0x00000172 FUNC LOCL H 0 .text
$dtrace9391.
[762] 0x00000000 0x00000000 FILE LOCL D 0 ABS
dtrace_data.
.SUNW_ldynsym lets us report names for static functions instead of hex addresses
when looking at stripped objects. For example, 'pstack' uses this, via libproc.
For more about this:
PSARC 2006/526 SHT_SUNW_LDYNSYM - default local symbol addition
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
>
I believe Rod filed the RTI for this today, so we're getting close.
- Ali
_______________________________________________
dtrace-discuss mailing list
[email protected]
