linux-kernel - Re: [rfd] function-graph augmentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090220140403.GC16897@ghostprotocols.net>
Date:	Fri, 20 Feb 2009 11:04:03 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Jason Baron <jbaron@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/