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
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

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)

versus:

_spin_lock(.lock={.raw_lock={.slock=0}})

All members should be collected? Just some? User decides?

- Arnaldo


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