From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1571 invoked by alias); 31 Mar 2009 20:42:46 -0000 Received: (qmail 1561 invoked by uid 22791); 31 Mar 2009 20:42:45 -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; Tue, 31 Mar 2009 20:42:37 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n2VKgJKi005560; Tue, 31 Mar 2009 22:42:19 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n2VKgIUx003764; Tue, 31 Mar 2009 22:42:18 +0200 (CEST) Date: Tue, 31 Mar 2009 20:49:00 -0000 Message-Id: <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: tromey@redhat.com CC: gdb-patches@sourceware.org In-reply-to: (message from Tom Tromey on Mon, 30 Mar 2009 17:00:56 -0600) 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> 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-03/txt/msg00710.txt.bz2 > From: Tom Tromey > Date: Mon, 30 Mar 2009 17:00:56 -0600 > > Resurrecting an old thread... > > Mark> It's the ID construction that I'm worried about. It is the very core > Mark> of the unwinding code. I really think your diff violates the most > Mark> fundamental principle of this bit of code and in that way, makes it > Mark> much harder to understand it. > > Daniel> I don't understand what you mean when you say this makes the generic > Daniel> code any harder to understand. Can you point to lines for me? > > [...] > > Daniel> If you can think of a way to do this that doesn't involve complicating > Daniel> the generic unwind machinery - exactly what we're both trying to avoid > Daniel> - I'll give it another shot. > > Mark, could you answer Daniel's questions? This patch has been in > limbo since last July. I'd like to at least know what needs to be > done to move forward on this. A bit hard after more than 9 months :(. IIRC Daniels diff really turned the whole stack unwinding upside down. > FWIW, we're shipping this in Archer. I think other organizations are > shipping it as well. Debugging inlined functions nicely is a > frequently requested feature; I answer questions about it on irc at > least once a week. 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.