From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2158 invoked by alias); 1 Dec 2004 23:51:48 -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 1145 invoked from network); 1 Dec 2004 23:51:27 -0000 Received: from unknown (HELO priv-edtnes57.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 1 Dec 2004 23:51:27 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041201235126.GWKD12146.priv-edtnes57.telusplanet.net@takamaka.act-europe.fr> for ; Wed, 1 Dec 2004 16:51:26 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id F1FBE47DA6; Wed, 1 Dec 2004 15:51:25 -0800 (PST) Date: Wed, 01 Dec 2004 23:51:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/alpha-osf] another next frame confusion in signal unwinder? Message-ID: <20041201235125.GL1001@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00036.txt.bz2 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 4190 Hello, Using the following C program: #include #include #include void blow_up (int x) { *((int*) (x|1)) = 3; } void handler (int sig) { blow_up (sig); printf ("This is a test.\n"); } main () { signal (SIGTERM, handler); kill (getpid (), SIGTERM); } Compiled on Tru64 5.1a with GCC: % gcc -g -o cause_signal cause_signal.c The following transcript reveals that GDB is unable to unwind the stack past the signal handler frame: (gdb) run Starting program: /usr/prague.a/brobecke/53-63/ex/cause_signal Program received signal SIGTERM, Terminated. 0x000003ff800e8a78 in kill () from /usr/shlib/libc.so (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0000000120001248 in blow_up (x=15) at cause_signal.c:7 7 *((int*) (x|1)) = 3; (gdb) bt #0 0x0000000120001248 in blow_up (x=15) at cause_signal.c:7 #1 0x0000000120001290 in handler (sig=15) at cause_signal.c:12 #2 #3 0xa79db5f0b43c0000 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0xa79db5f0b43c0000 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' +command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. #4 0x2c9000006bfa8001 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x2c9000006bfa8001 warning: Previous frame identical to this frame (corrupt stack?) The expected output for the "bt" command is: (gdb) bt #0 0x0000000120001248 in blow_up (x=15) at cause_signal.c:7 #1 0x0000000120001290 in handler (sig=15) at cause_signal.c:12 #2 #3 0x000003ff800e8a78 in kill () from /usr/shlib/libc.so #4 0x0000000120001318 in main () at cause_signal.c:20 When trying to compute the frame previous to the signal handler one, GDB computes the frame cache, and as a consequence ends up calling static struct alpha_sigtramp_unwind_cache * alpha_sigtramp_frame_unwind_cache (struct frame_info *next_frame, void **this_prologue_cache) { [...] info->sigcontext_addr = tdep->sigcontext_addr (next_frame); return info; } This results in a call to: static CORE_ADDR alpha_osf1_sigcontext_addr (struct frame_info *frame) { struct frame_info *next_frame = get_next_frame (frame); if (next_frame != NULL) return (read_memory_integer (get_frame_base (next_frame), 8)); else return (read_memory_integer (get_frame_base (frame), 8)); } It looks to me that we already have the next frame, so computing the next frame of that frame in alpha_osf1_sigcontext_addr() is making us using the wrong frame when getting the base address for the signal context area. So I changed this function to: static CORE_ADDR alpha_osf1_sigcontext_addr (struct frame_info *next_frame) { return (read_memory_integer (get_frame_base (next_frame), 8)); } This fixes the problem above, and I obtain the expected callstack. 2004-12-01 Joel Brobecker * alpha-osf1-tdep.c (alpha_osf1_sigcontext_addr): Change parameter name to make it clear that we already have a next frame. Return the sigcontext from that next frame instead of the frame following it. Fixes [DB30-017]. Tested on alpha-tru64 5.1a. No regression. OK to apply? -- Joel --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="signal.diff" Content-length: 827 Index: alpha-osf1-tdep.c =================================================================== RCS file: /nile.c/cvs/Dev/gdb/gdb-6.3/gdb/alpha-osf1-tdep.c,v retrieving revision 1.3 diff -u -p -r1.3 alpha-osf1-tdep.c --- alpha-osf1-tdep.c 21 Oct 2004 00:08:34 -0000 1.3 +++ alpha-osf1-tdep.c 1 Dec 2004 17:54:46 -0000 @@ -35,14 +35,9 @@ alpha_osf1_pc_in_sigtramp (CORE_ADDR pc, } static CORE_ADDR -alpha_osf1_sigcontext_addr (struct frame_info *frame) +alpha_osf1_sigcontext_addr (struct frame_info *next_frame) { - struct frame_info *next_frame = get_next_frame (frame); - - if (next_frame != NULL) - return (read_memory_integer (get_frame_base (next_frame), 8)); - else - return (read_memory_integer (get_frame_base (frame), 8)); + return (read_memory_integer (get_frame_base (next_frame), 8)); } static void --7JfCtLOvnd9MIVvH--