From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2700 invoked by alias); 22 Apr 2009 22:04:10 -0000 Received: (qmail 1992 invoked by uid 22791); 22 Apr 2009 22:04:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Apr 2009 22:03:56 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n3MM3WoT017614; Thu, 23 Apr 2009 00:03:32 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n3MM3Wo5001785; Thu, 23 Apr 2009 00:03:32 +0200 (CEST) Date: Wed, 22 Apr 2009 22:04:00 -0000 Message-Id: <200904222203.n3MM3Wo5001785@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: tromey@redhat.com, gdb-patches@sourceware.org In-reply-to: <20090420154909.GA5386@caradoc.them.org> (message from Daniel Jacobowitz on Mon, 20 Apr 2009 11:49:09 -0400) Subject: Re: [FYI] Inlining support, rough patch References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00617.txt.bz2 > Date: Mon, 20 Apr 2009 11:49:09 -0400 > From: Daniel Jacobowitz > > On Tue, Mar 31, 2009 at 10:42:18PM +0200, Mark Kettenis wrote: > > I agree that it is an important feature. I'll see if I can wrap my > > head around this again now that I'm not in an airport every other > > week again. > > Hi Mark, > > Did you have a chance to look at this? If not, maybe we can find a > third party to review the patch? If someone volunteers, I'll refresh > the diffs from our internal tree. Nothing algorithmic has changed, > but we have a few bug fixes and improved testcases. Yes, I did spent some of my time looking at the diff again, and thinking about the proper solution for the problem at hand. And I'm afraid that it has reinforced my initial opinion about your approach. Let me explain. The fundamental principle behind unwinding the stack is, given the register state of a process/thread executing code in a certain function, figuring out the register state at the point where this function was called. This register state may be incomplete because information that is no longer necessary for the program to continue past this point has been lost. However we assume that at least the stack pointer and program counter can be recovered (if not we terminate the unwinding). I firmly believe that if we want to add the capability to unwind through inlined functions, this fundamental principle should hold for inlined functions as well. This means that if we can detect that the current register state describes a process executing an inlined function we should faithfully reconstruct the register state for the call site of that inlined function. If I understand things correctly, the DW_TAG_inlined_subroutine tag provides information about the call site, which gives us the unwound program counter. But in order to reconstruct the complete register state, we need more information. The only viable source of that information is something like DWARF CFI; you don't stand a chance of doing a proper job here by doing instruction analysis. That is why I still think integrating inline support in the DWARF unwinder is the right way forward. I really think that unwinding further down the stack to get information for an inlined frame like you do in your diff is wrong, and I feel like you're digging a fairly deep hole for yourself here. That said, the proper response from me would be to hack up something closer to what the right solution would be. But I'm afraid I simply don't have the motivation to do such a thing anymore. The environment in which GDB is being developed seems to have changed. It feels like I'm the only one who is still hacking on code for fun, and that I'm being surrounded by people for which writing GDB code is their job. It sometimes feels like most of the effort goes into supporting debugging embedded targets hosted on non-free operating systems. And I increasingly find myself fighting against proposals to change development practices (C++, XML) and a mentality to fix bugs by slapping more code into GDB instead of taking some time and exploring alternative solutions. Perhaps the time has come for me to simply give up. Mark