From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22993 invoked by alias); 12 Nov 2005 02:38:12 -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 22974 invoked by uid 22791); 12 Nov 2005 02:38:09 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.205) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 12 Nov 2005 02:38:09 +0000 Received: by zproxy.gmail.com with SMTP id l1so840818nzf for ; Fri, 11 Nov 2005 18:38:08 -0800 (PST) Received: by 10.37.12.63 with SMTP id p63mr1933189nzi; Fri, 11 Nov 2005 18:38:08 -0800 (PST) Received: by 10.37.2.35 with HTTP; Fri, 11 Nov 2005 18:38:08 -0800 (PST) Message-ID: <8f2776cb0511111838m64d478d9s2e04db338fbf7fc8@mail.gmail.com> Date: Sat, 12 Nov 2005 04:22:00 -0000 From: Jim Blandy To: Randolph Chung Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning Cc: Joel Brobecker , gdb-patches@sources.redhat.com In-Reply-To: <437548AF.5090107@tausq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051109203108.GX1635@adacore.com> <43735815.3070805@tausq.org> <20051111001017.GJ1635@adacore.com> <437548AF.5090107@tausq.org> X-SW-Source: 2005-11/txt/msg00153.txt.bz2 On 11/11/05, Randolph Chung wrote: > 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. This is a question all the prologue analyzers have to answer. You can either stop when you reach the current PC, or stop when you see an instruction you don't recognize. > For that matter, how do you find the beginning of the function without > unwind data? Linker symbols. If you don't have them, then prologue analysis isn't usefu= l. > 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. In my experience, the new analysis framework (which I've kind of been forgetting about for a while now) makes things a lot more robust. I wrote it because I was getting fed up with corrupted backtraces debugging GDB on the S/390. With the new framework, I got a multi-page backtrace through optimized code the first time. It makes a big difference.