lkml.org 
[lkml]   [2009]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfd] function-graph augmentation

* Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> Em Fri, Feb 20, 2009 at 10:30:11AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Feb 20, 2009 at 09:56:27AM +0100, Ingo Molnar escreveu:
> > > 2)
> > >
> > > Another, entirely different, and i think complementary approach,
> > > which exciting new possibilities would be to (also)
> > > automatically pick up arguments from the stack, on function
> > > entry.
> > >
> > > If there's a (read-mostly, lockless-to-read and scalable)
> > > function attributes hash, then we could encode the parameters
> > > signature of functions (or at least, of certain functions) in
> > > the attributes hash. Then the tracer will know how many
> > > arguments to pick up from the stack.
> > >
> > > This approach has the advantage that we could reconstruct the
> > > parameters of _arbitrary_ functions, without having to touch
> > > those functions. We already enumerate all functions during build
> > > time, it would take some more dwarf2 magic to recover the
> > > call/parameter signature. Oh, and at that time we could also
> > > record the _return type_ - easing the return value.
> > >
> > > Note that it does not take a full, bloated DEBUG_INFO build - we
> > > can build a -g object to get the dwarf2 data and then strip out
> > > the dwarf2 data.
> > >
> > > Arnaldo, what do you think about this, how feasible would it be
> > > to put dwarf2 magic into scripts/recordmcount.pl?
> >
> > /me reading scripts/recordmcount.pl...
>
> So you want to:
>
> 1. build object with -g
> 2. just after it is built, get what we want from the DWARF sections,
> then strip it, stash what we collected
> 3. what we want is:
> - parameter names
> - _where_ each parameter is (DWARF location expressions)
> - type signature (CTF like stuff)
> 4. allow users to ask for parameters (all? just some?) for certain functions
> to be collected at function entry
> 5. at function entry check if parameters should be collected, go over
> each parameter DWARF location expression and collect the values,
> encoding them into the ring buffer
> 6. at cat /d/tracing/trace time pretty print the parameters collected,
> i.e. name=value-formatting-according-to-its-type

yeah.

> Ok, base types are easy, enums are easy, what about structs? forget
> about them and just print the pointer? i.e.:
>
> _spin_lock(.lock=0xabcdef)

yeah.

> versus:
>
> _spin_lock(.lock={.raw_lock={.slock=0}})
>
> All members should be collected? Just some? User decides?

I think we should concentrate on the simplest, most obvious use,
and iterate from there, gradually.

There's a lot of unknowns here - how reliable is the dwarf2 data
in practice: we _really_ dont want to trust dwarf2 data by
default becaus it can crash the kernel - so it's best to put it
in some trusted format controlled by us - just like recordmcount
works as a post-processor.

So if we have something simple and obvious and robust to start
from we'll know a lot more once we started using it.

Ingo


\
 
 \ /
  Last update: 2009-02-20 15:19    [W:0.331 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site