Thank you Ali!
Yes, you are right, the example I gave was not stripped.
By reading your blog I am now much more clear about the symbol tables in
ELF.
Therefore, DTrace obtains the local function names and address via
SUNW_ldynsym symbol table when .symtab section is gone ?
A very simple example is main( ) call foo( ), foo( ) is a local function in
the program. I stripped the
.symtab of this program, then I use DTrace and got the following result.
CALL(args) = return
-> _start(0x8047E50, 0x0, 0x8047E57)
-> __fsr(0x1, 0x8047D8C, 0x8047D94)
<- __fsr = 125
-> main(0x1, 0x8047D8C, 0x8047D94)
-> foo(0xA, 0x8047D64, 0xD17C6F04)
<- foo = 10
-> foo(0xA, 0x8047D64, 0xD17C6F04)
<- foo = 10
<- main = 83
Thanks!
Ling
> If I'm reading this correctly, DTrace is reporting on symbols found
> in the runtime linker (ld.so.1), which is not stripped. Stripping your
> object has no effect on the other system objects it is linked to, so it's
> not surprising that this works.
>
> However, you will find that Solaris can figure out most symbols of interest
> in your stripped object as well. As Adam points out, this comes from the
> dynamic
> symbol table, and the related SUNW_ldynsym symbol table, neither of which
> can be stripped. If the .symbtab is gone, the system is able to use these
> instead, and will be able to resolve all functions, as well as global data.
>
> Here are some things from my blog that you might help you understand
> more about the underpinnings:
>
> http://blogs.sun.com/ali/entry/inside_elf_symbol_tables
> http://blogs.sun.com/ali/entry/what_is_sunw_ldynsym
> http://blogs.sun.com/ali/entry/which_solaris_files_are_stripped
>
> I don't think you should strip your objects though --- there's little
> or any benefit, and it does hurt observability.
>
> Ali
>
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
