linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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]

Date:	Sat, 16 Sep 2006 01:52:24 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Karim Yaghmour <karim@...rsys.com>
Cc:	"Jose R. Santos" <jrs@...ibm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Andrew Morton <akpm@...l.org>, tglx@...utronix.de,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

* Karim Yaghmour <karim@...rsys.com> wrote:

> > So you dispute that markups for dynamic tracing will be more 
> > flexible and you dispute that they will be less intrusive than 
> > markups for static tracing?
> 
> No, I'm saying that the flexibility of the markup is not tied to the 
> instrumentation "grab" mechanism (direct call or binary editing.) 
> That's the "arbitrary" I'm talking about.

ok, then i'd like to dispute your point. Contrary to your statement 
there is a very fundamental difference between "static tracing" (static 
call, which relies on compile-time insertion of trace points) and 
"dynamic tracing" (which can insert trace points almost anywhere) - 
_even if both use in-source markers_.

The fundamental difference is this: dynamic tracing has full access to 
the full environment of the code that it taps into _at the time of 
tracepoint activation_, while static tracing has to get all its context 
during compilation.

To make my point easier to understand, consider the following example: 
we want to tap into the middle of a global_function():

 int global_function(int arg1, int arg2, int arg3)
 {
         ... [lots of code] ...

         x = func2();

         ... [lots of code] ...
 }

We want to trace the function right after 'x' has been assigned, and we 
want to trace an event_A, with parameters: arg1, arg2, arg3 and x. This 
is a pretty common scenario. Ok so far?

here is how the markup looks like under static tracing:

 int global_function(int arg1, int arg2, int arg3)
 {
         ... [lots of code] ...

         x = func2();
         D(event_A, arg1, arg2, arg3, x);

         ... [lots of code] ...
 }

that's what you'd expect, right? This is pretty common too, up to this 
point.

now how could the markup look like for a dynamic tracepoint:

 int global_function(int arg1, int arg2, int arg3)
 {
         ... [lots of code] ...

         x = func2();
         D(event_A, x);

         ... [lots of code] ...
 }

Note: there's no (arg1, arg2, arg3) passed to the markup! Why? Because 
SystemTap has full access to the function's arguments and in this 
particular case it's simply not necessary to reference them explicitly.
So the markup has less of an overhead because it does not 'touch' arg1,
arg2, arg3 if the tracepoint is not active [which is the common case we
optimize for].

Furthermore, the markup is also visually less intrusive.

But better than that, the markup could look like this as well:

 int global_function(int arg1, int arg2, int arg3)
 {
         ... [lots of code] ...

         x = func2();

         ... [lots of code] ...
 }

right, no markup at all, but in a script somewhere we'd have:

  insert.trace(global_function: "x = func2();", after);

or maybe even in a script, annotated in patch format, so that the 
context of the tapped code is captured too.

so, as a result: the dynamic markup() does the same, but has less impact 
on the compiled code (less parameters touched), and is more flexible in 
terms of attachment to the source code.

Can we do any of this with the static tracepoint? We cannot, 
fundamentally! So if we allowed static tracers to access that tracepoint 
anytime, we could never make things more intelligent there in the 
future!

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