From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27586 invoked by alias); 9 Dec 2005 04:55:25 -0000 Received: (qmail 27577 invoked by uid 22791); 9 Dec 2005 04:55:24 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 04:55:22 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id jB94tGqO006336; Thu, 8 Dec 2005 23:55:17 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id jB94tEJq006334; Thu, 8 Dec 2005 23:55:14 -0500 (EST) Message-Id: <200512090455.jB94tEJq006334@hiauly1.hia.nrc.ca> Subject: Re: [hpux] interesting but difficult to unwind code To: randolph@tausq.org (Randolph Chung) Date: Fri, 09 Dec 2005 04:55:00 -0000 From: "John David Anglin" Cc: brobecker@adacore.com, gdb@sources.redhat.com In-Reply-To: <4398FB10.1050307@tausq.org> from "Randolph Chung" at Dec 9, 2005 11:33:36 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00096.txt.bz2 > > No, this code has been compiled by GCC. The save of the frame > > pointer at the incomming stack pointer address is the clue. SAVE_SP > > should be set to indicate this. This should allow unwinding > > through this function... > > hrm, is there a way to verify this other than the above? The fact that > the "args_stored" flag is set in the unwind record is also a bit > surprising, as (afaict) gcc doesn't emit this flag. > > I downloaded this wdb binary from HP's website and their documentation > also seems to suggest that it is compiled with HP compilers. I've changed my mind. This code is compiled by a HP compiler. So, it better be ABI compliant. I was confused by the code that has been moved into the prologue. GCC doesn't set "args_stored". The register saves for r4, r5 and r6 are in different locations than gcc would use. On checking, the frame marker copy is slightly different. Gcc doesn't copy slot at "-10" and we actually save the previous stack pointer at sp - 4 when the frame pointer is needed. > >> 1) it has a branch right in the middle of the prologue at +16. This is a > >> call to strlen() > > > > Interesting. It looks ok from a functional standpoint. > > Yes, but I've never seen gcc do this.... does it? I've never seen it but in theory it could. > >> (gdb) maintenance print unwind execute_command > >> unwind_table_entry (0x40286424): > >> region_start = 0xcb44c > >> region_end = 0xcb798 > >> flags = Args_stored Save_RP > > > > I don't understand why you don't see SAVE_SP in the flags. It looks as if r3 is used as the argument pointer (previous stack pointer) but there aren't any flag bits set to indicate this. The only indication is the copy at 0x000cb454. I guess if you detect this you have to take it as a matter of faith that the contents of r3 don't change. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)