Francois Dion wrote:> Le lundi 16 avril 2007 ? 13:28 -0600, Ali Bahrami a ??crit :
>>> Subject:
>>> Re: [dtrace-discuss] Getting the function names?
>>> From:
>>> Bart Smaalders <bart.smaalders at Sun.COM>
>>> Date:
>>> Fri, 13 Apr 2007 09:48:29 -0700
>>> To:
>>> fdion at atriumwindows.com
>>>
>>> To:
>>> fdion at atriumwindows.com
>>> CC:
>>> dtrace-discuss <dtrace-discuss at opensolaris.org>
>>>
>>>
>>> Francois Dion wrote:
>>>> I got a c++ app, called from sun web server (hence my previous
question
>>>> of how to instrument a short lived process). I created a
framework that
>>>> fakes the client/sun web server and executes the application
through a
>>>> dtrace call with -c so I can use the pid provider.
>>>>
>>>> I instrumented to get a count of functions. A *lot* of malloc
(and the
>>>> mutex locking/unlocking associated with that, although this is
a single
>>>> threaded app, I wish I could use a straight non MT malloc).
Anyway, I
>>>> then used a count of similar calls:
>>>>
>>>> pid$target:libc:malloc:entry
>>>> {
>>>> @[ustack()]=count();
>>>> }
>>>>
>>>> As the script that runs when calling -c app.cgi
>>>>
>>>> I found the biggest culprit here:
>>>>
>>>> app.cgi`malloc
>>>> libCrun.so.1`__1c2n6FL_pv_+0x28
>>>>
>>>>
libCstd.so.1`__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJalloc
>>>>
ator4Cc___I__getRep6MLL_pnH__rwstdM__string_ref4Ccn0B_n0C____+0x50
>>>>
>>>>
libCstd.so.1`__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJalloc
>>>> ator4Cc___Hreplace6MLLLc_r1_+0x298
>>>> 0x10003624c
>>>> 0x1000f2d7c
>>>> 0x1000f1bf4
>>>> 0x1000efc8c
>>>> 0x1000efb28
>>>> 0x100099230
>>>> 0x100098034
>>>> 0x10003a5d0
>>>> app.cgi`_start+0x17c
>>>> 64785
>>>>
>>>> 64K calls on this! Everything else is a low count in
comparison. I know
>>>> this is unintentional, due to a bug.
>>>>
>>>> This is a c++ app, compiled with Sun Studio 12 EA1, on a sun
blade, as
>>>> debug, with symbols, then run on a sun t1000. I also tried with
release
>>>> mode (and xarch=v9b, xtarget=ultraT1, xchip=ultraT1). Neither
were
>>>> stripped, but result is the same. How do I get names instead of
>>>> addresses on the stack dump?
>>>>
>>>> nm app.cgi does show the symbol names etc.
>>>>
>>>> Thanks
>>>> _______________________________________________
>>>> dtrace-discuss mailing list
>>>> dtrace-discuss at opensolaris.org
>>> It looks like you have a lot of local functions... if you can try
>>> this on a machine running the latest OpenSolaris bits, I think
you''ll be
>>> able to see those functions w/o difficulty. This works on my build
60
>>> desktop.
>>>
>>> - Bart
>>>
>>>
>> Rod forwarded the above to me on Friday, and I''ve been waiting
for it
>> to show up on the opensolaris dtrace-discuss web interface so that I
could read
>> the entire thread before sending this. It hasn''t shown up yet,
so I''m just
>> going to send this mail now, and hope that it helps. Sorry for posting
blind
>> (and I''ll get myself signed up for dtrace-discuss ASAP)...
>>
>> I believe that dtrace is using libproc to map those addresses to names,
and
>> in that context, local function symbols were not available until
>>
>> PSARC 2006/526 SHT_SUNW_LDYNSYM - default local symbol addition
>> 4934427 runtime linker should load up static symbol names visible to
dladdr()
>>
>> which went into Nevada build 50, back in October. However, they
didn''t really become
>> useful until
>>
>> 6475315 libproc should take advantage of new .SUNW_ldynsym ELF
sections
>>
>> which went into build 56, in January.
>>
>> None of this has been moved back to S10 yet, so OpenSolaris bits are
the only way
>> to get access to it. Note that simply moving your compiled code to an
OpenSolaris
>> machine won''t do the trick. You''ll need to re-link it
on that OpenSolaris system
>> in order to generate the new ELF local symbol table section that
libproc will then
>> read.
>>
>> General background info about these local function symbol sections can
be found at
>>
>> http://blogs.sun.com/ali/entry/what_is_sunw_ldynsym
>>
>> - Ali
>
>
> Thanks for that extra info. I''m on B57 on my desktop, so I
recompiled
> there and got the full text stack. Do you think this will make it to U4
> of Solaris 10?
>
> I noticed also that under Sun Studio 12 EA1, with dbx runtime checking,
> I get addresses instead of names on the allocation call stack column. On
> B57. Is this somehow related?
>
> Thanks,
> Francois
I don''t think it will be in U4.
The dbx issue is definitely related --- dbx needs to be modified to use the
new ELF sections too. There is a CR for it:
6512413 Solaris 11 has additional symbols available - dbx should read them
The compiler guys know about it (they filed the CR), but I don''t know
what their
schedule is.
- Ali
