dtrace discuss - Jan 2009 - Sidebar to Systemtap and Dtrace Comparison

My leaky memory says we moved entry-point
into some form of debug record in the
standard libraries, circa Solaris 8/9.

Before that, my group maintained text files that
listed all the entry-points and their parameters for
libraries like libc.so, so that we could print
out parameter values in apptrace(8).

There''s a (small) chance the records are complete enough
that dtrace could use the debug records from the
system libraries, and in principle any library with
the right information available.

I *don''t* know whether they are complete enough: that
was done after my time in the ABI team.

--dave



Jon Haslam <Jonathan.Haslam at Sun.COM> wrote:
> Yes, having user-land type information would allow you
> to do what you want here. As I said, it''s something we know
> users would like but it would be a piece of work to implement.

"P. Remek" <p.remek1 at googlemail.com>
asked:
>> First thing that crossed my mind: We provide application to our
customers
>> and we provide support for it. When we release new version there are
usually
>> issues reported by customer. After some time I''ve realized
that most of
>> the issues (let''s say 50%) will appear (or let''s say
affect)
>> function''s parameters
>> on some level of execution. Right now we have tracing macros directly
>> compiled into our application for each function''s return/exit
which
>> logs function
> > parameters as well as function name. By observing it I am usually able
>> to quickly locate
>> culprit of the issue. Problem is that we have to maintain all those
>> tracing macros
>> in the code. With dtrace I am able to get only function''s name
(as it
>> is in ABI)
>> with one general "pid$1:::entry". As per my understanding
there is no
>> way to define
>> function parameters logging generally.I would need to let''s
say
>> include header file
>> with function''s prototypes and manually create probe for each
>> function.  To have
> > better idea there is an application which I have tried which does
> > similar thing on
> > windows platform: www.autodebug.com.
> >
> > Remek
-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb at sun.com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#

Hi Dave,

All of that information was discarded in favor of CTF data. In fact,
apptrace now just uses CTF data to symbolically print function  
arguments.
It was always the plan to have DTrace use this user-land CTF data.

Adam

On Jan 21, 2009, at 10:26 AM, David Collier-Brown wrote:
>  My leaky memory says we moved entry-point
> into some form of debug record in the
> standard libraries, circa Solaris 8/9.
>
> Before that, my group maintained text files that
> listed all the entry-points and their parameters for
> libraries like libc.so, so that we could print
> out parameter values in apptrace(8).
>
> There''s a (small) chance the records are complete enough
> that dtrace could use the debug records from the
> system libraries, and in principle any library with
> the right information available.
>
> I *don''t* know whether they are complete enough: that
> was done after my time in the ABI team.
>
> --dave
>
>
>
> Jon Haslam <Jonathan.Haslam at Sun.COM> wrote:
>> Yes, having user-land type information would allow you
>> to do what you want here. As I said, it''s something we know
>> users would like but it would be a piece of work to implement.
>
>
> "P. Remek" <p.remek1 at googlemail.com> asked:
>>> First thing that crossed my mind: We provide application to our  
>>> customers
>>> and we provide support for it. When we release new version there
are
> usually
>>> issues reported by customer. After some time I''ve realized
that
>>> most of
>>> the issues (let''s say 50%) will appear (or let''s
say affect)
>>> function''s parameters
>>> on some level of execution. Right now we have tracing macros  
>>> directly
>>> compiled into our application for each function''s
return/exit which
>>> logs function
>>> parameters as well as function name. By observing it I am usually  
>>> able
>>> to quickly locate
>>> culprit of the issue. Problem is that we have to maintain all those
>>> tracing macros
>>> in the code. With dtrace I am able to get only function''s
name (as
>>> it
>>> is in ABI)
>>> with one general "pid$1:::entry". As per my understanding
there is
>>> no
>>> way to define
>>> function parameters logging generally.I would need to
let''s say
>>> include header file
>>> with function''s prototypes and manually create probe for
each
>>> function.  To have
>>> better idea there is an application which I have tried which does
>>> similar thing on
>>> windows platform: www.autodebug.com.
>>>
>>> Remek
>
> -- 
> David Collier-Brown            | Always do right. This will gratify
> Sun Microsystems, Toronto      | some people and astonish the rest
> davecb at sun.com                 |                      -- Mark Twain
> cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl