From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5674 invoked by alias); 12 Nov 2005 01:43:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5659 invoked by uid 22791); 12 Nov 2005 01:43:26 -0000 Received: from ip127.bb146.pacific.net.hk (HELO stl.com.hk) (202.64.146.127) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 12 Nov 2005 01:43:26 +0000 Received: from rccomp.stl.com.hk ([192.168.100.200]) by stl.com.hk with esmtp (Exim 4.50) id 1EakNJ-0000XU-8i; Sat, 12 Nov 2005 09:40:13 +0800 Message-ID: <437548AF.5090107@tausq.org> Date: Sat, 12 Nov 2005 03:32:00 -0000 From: Randolph Chung User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050805) MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning References: <20051109203108.GX1635@adacore.com> <43735815.3070805@tausq.org> <20051111001017.GJ1635@adacore.com> In-Reply-To: <20051111001017.GJ1635@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00152.txt.bz2 > After your feedback, I'm starting to think that this whole unwind > record thing is a wasp nest. This is loud thinking at this stage, > but let me suggest something heretical: How about to stop using > the unwind record to do the unwinding? We scan the prologue as we've > always done, and collect all the information, including the fact that > the function has a frame pointer or not. Then we don't need use > the unwind record, except maybe to determine the function start > address. I think we might even be able to dump the FP_REGNUM > entirely. How do you find the end of the prologue without consulting the unwind data? Right now one heuristic is "scan the code until you hit a branch", which works but might mean you scan way too much code. I'm also not certain if this will work correctly for things like alloca, but it might. For that matter, how do you find the beginning of the function without unwind data? Right now the hppa backend can determine this even in the absence of other debug (stabs, dwarf) info, although it might end up printing the wrong function name in a backtrace. > The good thing is that I don't think we'll need that many changes > to the code to get to that point. Improve a bit the code scanner > to retrieve the information that we normally dig out of the unwind > record, and we should have something at least marginally working. > The other advantage is that now the debugger doesn't need to know > what compiler produced the object. So I'll be able to share the changes > we make internally too. What do you think? Making gdb more compiler independent is of course a good thing, but I don't know that we want to get rid of the unwind record altogether. OTOH, if you can combine all the prologue analysis code in hppa-tdep.c and make it more robust, I think it will certainly be a good thing. randolph