This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello, Using the following C program: #include <signal.h> #include <stdio.h> #include <unistd.h> 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 <signal handler called> #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 <signal handler called> #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 <brobecker@gnat.com> * 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
Attachment:
signal.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |