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]

Message-Id: <1158279588.2474.21.camel@entropy>
Date:	Thu, 14 Sep 2006 17:19:48 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Martin Bligh <mbligh@...igh.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>, fche@...hat.com
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

On Fri, 2006-09-15 at 01:19 +0200, Ingo Molnar wrote: 
> but i think (and i think now you'll be surprised) the way to go is to do 
> all this in SystemTap ;-) If we add any static points to the kernel then 
> it should have a pure 'local data preparation for extraction' purpose - 
> nothing more. Static tracing can be built around that too, but at that 
> point it will be unnecessary because SystemTap will be able to do that 
> too, with the same (or better, considering the LTT mess) performance.
> 
> i.e. we should have macros to prepare local information, with macro 
> arities of 2, 3, 4 and 5:
> 
>     _(name, data1);
>    __(name, data1, data2);
>   ___(name, data1, data2, data3);
>  ____(name, data1, data2, data3, data4);
> 
> that and nothing more. But no guarantees that these trace points will 
> always be there and usable for static tracers: for example about 50% of 
> all tracepoints can be eliminated via a function attribute. (which 
> function attribute tells GCC to generate a 5-byte NOP as the first 
> instruction of the function prologue.) That will be invariant to things 
> like function renames, etc.

Another interesting idea would be the addition to gcc of a:

__builtin_trace_point(char *name, ...)

It would output a function call sized NOP at it's call site, and store
in another section the trace point name, location, and (this is the
important part) a series of DWARF expressions to reconstruct the trace
point's argument list from the stack frame and saved registers.

This would completely eliminate the argument passing overhead of a
patched-out function call in the cases where the trace point takes
arguments.

It'd also make your __trace function attribute unnecessary, because gcc
could presumably figure out that the trace point is at the beginning of
the function.

It "only" requires compiler support on every architecture that the
kernel cares about and compiler upgrades for everyone who wants to use
static trace points, which is no mean feat.

(Roman Zippel was trimmed from the CC list because his server is
rejecting mail from me and/or Comcast. If the first attempts actually
make it through and this is yet another duplicate, sorry.)

-- 
Nicholas Miell <nmiell@...cast.net>

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