Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: gdb-patches@sources.redhat.com
Subject: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame
Date: Fri, 20 Feb 2004 21:27:00 -0000	[thread overview]
Message-ID: <40367BCD.8090403@gnu.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Ref: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()
http://sources.redhat.com/ml/gdb-patches/2004-01/msg00104.html

Having only recently posted:
> Can just you add a -ve comment stating why a test for PC==0 does not belong in that function? I'm pretty much certain that someone will eventually try to re-add a very similar test (via inside_entry_func for instance).

the attached adds a conditionalized check for "PC == 0" to 
get_prev_frame.  If there's a zero PC, _and_ it isn't the inner most 
frame, stop unwinding.  That should let mark's original case through.

Turns out that the old removed test was stopping this problem on amd64:

(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's 
print
where
#0  print_philosopher (n=3, left=33 '!', right=33 '!') at 
/home/cygnus/cagney/GD
B/src/gdb/testsuite/gdb.threads/linux-dp.c:105
#1  0x0000000000400e4a in philosopher (data=0x50177c) at 
/home/cygnus/cagney/GDB
/src/gdb/testsuite/gdb.threads/linux-dp.c:148
#2  0x0000002a95671c2b in start_thread () from /lib64/tls/libpthread.so.0
#3  0x0000002a959de040 in thread_start () from /lib64/tls/libc.so.6
#4  0x0000000000000000 in ?? ()
#5  0x0000000000000000 in ?? ()
#6  0x0000000000000000 in ?? ()
#7  0x0000000000000000 in ?? ()
#8  0x0000000000000000 in ?? ()
#9  0x0000000000000000 in ?? ()
#10 0x0000000000000000 in ?? ()
#11 0x0000000000000000 in ?? ()
#12 0x0000000000000000 in ?? ()
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x0000002a95b41580 in _nl_C_locobj () from /lib64/tls/libc.so.6
#17 0x00000000427ffdc8 in ?? ()

comments (...)
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1955 bytes --]

2004-02-20  Andrew Cagney  <cagney@redhat.com>

	* frame.c (get_prev_frame): With the exception of the inner-most
	frame, do not backtrace past a frame with a zero pc.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.162
diff -u -r1.162 frame.c
--- frame.c	16 Feb 2004 21:49:21 -0000	1.162
+++ frame.c	20 Feb 2004 21:12:52 -0000
@@ -1721,14 +1721,9 @@
   return prev;
 }
 
-/* Return a structure containing various interesting information
-   about the frame that called THIS_FRAME.  Returns NULL
-   if there is no such frame.
-
-   This function tests some target-independent conditions that should
-   terminate the frame chain, such as unwinding past main().  It
-   should not contain any target-dependent tests, such as checking
-   whether the program-counter is zero.  */
+/* Return a structure containing various interesting information about
+   the frame that called THIS_FRAME.  Returns NULL if there is no such
+   frame.  */
 
 struct frame_info *
 get_prev_frame (struct frame_info *this_frame)
@@ -1843,6 +1838,24 @@
 	  fprint_frame (gdb_stdlog, NULL);
 	  fprintf_unfiltered (gdb_stdlog, "// inside entry func }\n");
 	}
+      return NULL;
+    }
+
+  /* Don't allow frames with a zero PC to unwind.  The exception is
+     the inner-most frame - a jump through a NULL pointer results in
+     an inner most frame that is both unwindable and has a zero
+     PC.  */
+  /* NOTE: cagney/2004-02-20: The old zero PC check, removed
+     2004-01-11, had the problem that it stopped backtraces from that
+     inner most zero PCed frame.  */
+  if (this_frame->level > 0 && get_frame_pc (this_frame) == 0)
+    {
+      if (frame_debug)
+        {
+          fprintf_unfiltered (gdb_stdlog, "-> ");
+          fprint_frame (gdb_stdlog, NULL);
+          fprintf_unfiltered (gdb_stdlog, " // PC zero }\n");
+        }
       return NULL;
     }
 

             reply	other threads:[~2004-02-20 21:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-20 21:27 Andrew Cagney [this message]
2004-02-20 23:23 ` Mark Kettenis
2004-02-22 17:40   ` Andrew Cagney
2004-02-22 21:10     ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40367BCD.8090403@gnu.org \
    --to=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox