From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933527AbYDYWnd (ORCPT ); Fri, 25 Apr 2008 18:43:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757916AbYDYWnW (ORCPT ); Fri, 25 Apr 2008 18:43:22 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:45874 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755213AbYDYWnU (ORCPT ); Fri, 25 Apr 2008 18:43:20 -0400 Date: Fri, 25 Apr 2008 15:36:40 -0700 (PDT) From: Linus Torvalds To: Mathieu Desnoyers cc: "H. Peter Anvin" , Andi Kleen , Ingo Molnar , Jiri Slaby , David Miller , zdenek.kabelac@gmail.com, rjw@sisk.pl, paulmck@linux.vnet.ibm.com, akpm@linux-foundation.org, linux-ext4@vger.kernel.org, herbert@gondor.apana.org.au, penberg@cs.helsinki.fi, clameter@sgi.com, linux-kernel@vger.kernel.org, pageexec@freemail.hu, Jeremy Fitzhardinge Subject: Re: [PATCH 1/1] x86: fix text_poke In-Reply-To: <20080425223015.GB31226@Krystal> Message-ID: References: <20080425170929.GA16180@Krystal> <20080425183748.GB16180@Krystal> <48123C9B.9020306@zytor.com> <20080425203717.GB25950@Krystal> <481241DC.3070601@zytor.com> <20080425211205.GC25950@Krystal> <481249FB.8070204@zytor.com> <20080425214704.GD25950@Krystal> <48125635.3060303@zytor.com> <20080425223015.GB31226@Krystal> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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