From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26633 invoked by alias); 12 Nov 2005 04:39:43 -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 26621 invoked by uid 22791); 12 Nov 2005 04:39:40 -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 04:39:40 +0000 Received: from rccomp.stl.com.hk ([192.168.100.200]) by stl.com.hk with esmtp (Exim 4.50) id 1Ean7h-0001tk-3v; Sat, 12 Nov 2005 12:36:17 +0800 Message-ID: <437571F4.8020508@tausq.org> Date: Sat, 12 Nov 2005 13:21:00 -0000 From: Randolph Chung User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050805) MIME-Version: 1.0 To: Jim Blandy CC: Joel Brobecker , 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> <437548AF.5090107@tausq.org> <8f2776cb0511111838m64d478d9s2e04db338fbf7fc8@mail.gmail.com> <4375624D.1070202@tausq.org> <8f2776cb0511112022k746e7909r24be2e964dd45a13@mail.gmail.com> In-Reply-To: <8f2776cb0511112022k746e7909r24be2e964dd45a13@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00157.txt.bz2 > Hmm. Is it possible to find a function's entry point from a PC within > that function's code given only the unwind records? If the detailed There is one unwind record for each function. The unwind record contains the start and end address of the function. So yes, given a pc, we can find the unwind record and recover the starting address of the function. > contents of the unwind records are difficult to interpret accurately, > but we can accurately recover entry points from them, and prologue > analysis works, then we could use the unwind records *only* to > discover entry points, and then use prologue analysis to actually get > the unwind information. Well.... 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. Now, there is a trick to this -- how do we know we are after the prologue? Currently, we look at the unwind record which tells us what information is stored in the frame, and we do code analysis to determine the pc where all the information that the unwind record says should be in the frame has been stored in the frame. We used to not do this, and in fact hppa-tdep.c has a few variations of ways to "skip the prologue" :-( The more efficient way to determine the end of the prologue is to use debug info (i.e. we do what most backends do with find_pc_partial_function and find_pc_line). Sometime last year I changed this to always do code walking to better work with optimized functions. Note that in this case we are only counting instructions and not really "remembering" where things are. Then we check to see if the pc is after the prologue. If it is not, we do more prologue analysis and code walking to figure out what to do. You might think this is all rather circular, and it is. I agree with what you said below, that is: > I'm sounding like some kind of prologue analysis fanatic here, but > really I'm not. We should make the best use of the techniques and > information available, and it sounds to me like prologue analysis is > comparable with the alternatives here, if we can find the information > it needs. I'm all for cleaning up the code; I just think we need to be careful because of all the "twists" in the hppa ABI... especially on HPUX :( Just take a look at hppa_hpux_push_dummy_code sometime. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/