[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0804251534420.2779@woody.linux-foundation.org>
Date: Fri, 25 Apr 2008 15:36:40 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc: "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
Ingo Molnar <mingo@...e.hu>, Jiri Slaby <jirislaby@...il.com>,
David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
penberg@...helsinki.fi, clameter@....com,
linux-kernel@...r.kernel.org, pageexec@...email.hu,
Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH 1/1] x86: fix text_poke
On Fri, 25 Apr 2008, Mathieu Desnoyers wrote:
>
> DWARF2 is capable of extracting information only when not optimized away
> by the compiler. That's the whole point of markers : liveness is good in
> this case because we make sure the variable is there, not that it
> *might* be there. The latter case might be good enough for a debugger,
> but not for a production system tracer.
This is why you really do want to recompile the function entirely if
you're debugging it. Because it might simply not be debuggable in its
normal state.
I'd much rather see something truly generic that doesn't need any
pre-inserted "markers" at all that disable optimizations, and that allows
just about anything. Including live system bug-fixes etc (imagine finding
a bug - and not at somethign that was previously already "marked" - and
just replacing the buggy function with a non-buggy one).
Linus
--
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