From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28159 invoked by alias); 13 Nov 2005 18:12:45 -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 28146 invoked by uid 22791); 13 Nov 2005 18:12:42 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 13 Nov 2005 18:12:42 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id DBC8E48CDAA; Sun, 13 Nov 2005 13:12:40 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16265-01-5; Sun, 13 Nov 2005 13:12:40 -0500 (EST) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id 622A648CDA3; Sun, 13 Nov 2005 13:12:40 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id A35F847E79; Sun, 13 Nov 2005 10:12:35 -0800 (PST) Date: Sun, 13 Nov 2005 18:23:00 -0000 From: Joel Brobecker To: Randolph Chung Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning Message-ID: <20051112060426.GT1635@adacore.com> References: <20051109203108.GX1635@adacore.com> <43735815.3070805@tausq.org> <20051111001017.GJ1635@adacore.com> <437548AF.5090107@tausq.org> <8f2776cb0511111838m64d478d9s2e04db338fbf7fc8@mail.gmail.com> <4375624D.1070202@tausq.org> <8f2776cb0511112022k746e7909r24be2e964dd45a13@mail.gmail.com> <437571F4.8020508@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437571F4.8020508@tausq.org> User-Agent: Mutt/1.4i Resent-From: brobecke@adacore.com Resent-Date: Sun, 13 Nov 2005 10:12:35 -0800 Resent-To: randolph@tausq.org, jimb@red-bean.com, gdb-patches@sources.redhat.com Resent-Message-Id: <20051113181235.A35F847E79@takamaka.act-europe.fr> X-SW-Source: 2005-11/txt/msg00167.txt.bz2 > If we have an unwind record (and we should for any ABI-conforming > function), and the pc is after the prologue, then theoretically we don't > need to do prologue analysis. Just to throw a bit my twist on this interesting discussion :) This is of course in theory, but the problem is that we're seeing deviations from the ABI. GCC mades its own changes, we at AdaCore were more or less forced to change a few other things too (mostly IIRC to make sur that the HPUX unwinder would be able to unwind mixed HP/GCC code), and now I'm learning that even the HP C compiler might have its own little modifications. So there is really no compiler we can trust in following the manufacturer's documentation. So trying to interpret the unwind record properly seems pretty tricky to get right on HP/UX. I'm starting to agree with Jim that it might be a good to do prologue scanning regardless of where we are. Provided that reading memory regions in the inferior (analyzing instruction after instruction) is not too slow, the performance should still be pretty good. I used to think that PA-Risc is a complex chip. It is, in a sense, at least for the compiler maintainers. But for unwinding, I'm definitely seeing patterns, and all the examples I've seen so far seem (only seem) to indicate that prologue analysis should be relatively easy to do and get right. I think this begs for an experiment, which I hope I'll be able to make sometime during the winter. I can start with the code we have, since we already have a lot of code that analyzes the prologue, and see how to reconstitute the information we would otherwise get from the unwind record. On the other hand, we're starting to collect a lot of data, and there may be some ways to interpret this information properly. If we do, I think one good thing would be to isolate the actual interpretation from the unwinder. Move all the knowledge of how to read that record away, so that the unwinder has an interface that doesn't depend on the compiler. Randolph I think raised a very good point regarding the computation of the end of the prologue, though. I don't know if we can determine this without the help of the unwind record. For this, I don't have enough experience with that chip. One last precision, regarding the unwind record. Although probably 99.9% of the time we have one unwind record = one function, I learned from a customer report that this is not always the case. Sometimes, one function will have more than one unwind record. So an unwind record covers a region. It may or may not have a prologue, and may or may not have an epilogue. Fortunately, this is something we can handle thanks to the Region_description field. -- Joel