Messages in this thread | | | Date | Fri, 20 Feb 2009 15:17:07 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |