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
| ||
|
Date: Mon, 18 Sep 2006 08:25:27 -0400 From: "Frank Ch. Eigler" <fche@...hat.com> To: Ingo Molnar <mingo@...e.hu> Cc: Karim Yaghmour <karim@...rsys.com>, Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>, Paul Mundt <lethal@...ux-sh.org>, linux-kernel <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>, Roman Zippel <zippel@...ux-m68k.org>, Tom Zanussi <zanussi@...ibm.com>, Richard J Moore <richardj_moore@...ibm.com>, "Frank Ch. Eigler" <fche@...hat.com>, Michel Dagenais <michel.dagenais@...ymtl.ca>, Christoph Hellwig <hch@...radead.org>, Greg Kroah-Hartman <gregkh@...e.de>, Thomas Gleixner <tglx@...utronix.de>, William Cohen <wcohen@...hat.com>, "Martin J. Bligh" <mbligh@...igh.org> Subject: Re: tracepoint maintainance models Hi - mingo wrote: > [...] > static int x; > void func(int a) > MARK(event, a); > > if a dynamic tracer installs a probe into that MARK() spot, it will > have access to 'a', but it can also have access to 'x'. While a > static in-source markup for _static tracers_, if it also wanted to > have the 'x' information, would also have to add 'x' as a parameter: > [...] Without heroic measures taken by by a static tracer type of tool, this is correct. > For dynamic tracers no such 'parameter preparation' instructions > would need to be generated by gcc. (thus for example the runtime > overhead would be lower for inactive tracepoints) Any such additional code would be small, plus if properly marked up with unlikely() and compiled with -freorder-blocks, it would all be out-of-line. This small cost could be worth the added benefit of systemtap being able to probe that point without debugging information present, and avoiding its slow & deliberate way of accessing target-side variables like $x. (The slow & deliberate part comes in from the need to check any pointer dereferences involved.) - FChE - 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/
Powered by blists - more mailing lists