From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24697 invoked by alias); 17 Dec 2004 02:43:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24656 invoked from network); 17 Dec 2004 02:43:38 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org with SMTP; 17 Dec 2004 02:43:38 -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 iBH2hYko013141; Thu, 16 Dec 2004 21:43:34 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id iBH2hXwX013139; Thu, 16 Dec 2004 21:43:33 -0500 (EST) Message-Id: <200412170243.iBH2hXwX013139@hiauly1.hia.nrc.ca> Subject: Re: [RFC] Modernize HP-UX core file handling To: gdb-patches@sources.redhat.com Date: Fri, 17 Dec 2004 06:52:00 -0000 From: "John David Anglin" Cc: randolph@tausq.org, brobecker@adacore.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00398.txt.bz2 > found where all registers are saved. We know before scanning the > instrunctions that the SP was saved, but we don't know that the register > containing the old SP has itself been saved on the stack. Huh? GCC uses r3 as the frame pointer. When a frame pointer is needed, SAVE_SP is set. When SAVE_SP is set, current GCC versions save the old SP at SP-4. The SP-4 is set in the prologue and whenever a dynamic stack allocation is performed. Unfortunately, old versions of GCC don't correctly save the old SP at SP-4. However, r3 always contains the old SP when SAVE_SP is set. HP compilers don't set SAVE_SP. The SP-4 support was added to GCC to fix a problem with the HP-UX unwind library. I'm not surprised that gdb didn't see the save at SP-4 as this is a relatively new GCC feature under HP-UX (this isn't done under linux). This was for better support of the frame marker. Note the frame marker moves in a dynamic stack allocation (i.e, the old SP is always at SP-4). Thus, if SAVE_SP is set and you see a save to SP-4 in the prologue, the old SP can always be found at SP-4. Since r3 is a callee-saves register, it has to be saved on the stack when SAVE_SP is set in the unwind info. Hope that helps. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)