Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org
Cc: "Maciej W. Rozycki" <macro@codesourcery.com>,
		Andrew Stubbs <ams@codesourcery.com>,
		Vladimir Prus <vladimir@codesourcery.com>,
		Eli Zaretskii <eliz@gnu.org>
Subject: RFC: Fix "break *EXP thread NUM"
Date: Mon, 23 Nov 2009 21:27:00 -0000	[thread overview]
Message-ID: <20091123212736.GA3828@caradoc.them.org> (raw)

This issue has come up several times over the years.  I've CC'd a
couple of folks from the last discussions I found in the list
archives.  Here's an example:

(gdb) # OK
(gdb) break main thread 999
Unknown thread 999.
(gdb) # NG
(gdb) break *main thread 999
A syntax error in expression, near `thread 999'.

References:

http://sourceware.org/ml/gdb-patches/2005-04/msg00092.html
http://sourceware.org/ml/gdb-patches/2005-04/msg00116.html
http://sourceware.org/ml/gdb-patches/2006-07/msg00412.html

The problem is with the expression parser, which has no way to detect
the "end" of an expression (a poorly defined concept).  Since "if" can
not be a valid C identifier, and we do not parse C statements (just
expressions), we have a special technique in the lexer to detect that
token and stop.  So both of these work:

(gdb) break main if 999
Breakpoint 1 at 0x44cce0
(gdb) break *main if 999
Note: breakpoint 1 also set at pc 0x44cce0.
Breakpoint 2 at 0x44cce0

In this patch, I have taken advantage of the fact that even if you
have a local variable named "thread", there is no valid C expression
which has a variable name, whitespace, and an integer or floating
point constant.  So "thread [0-9]" can also safely be treated
as an expression terminator.

Does anyone see a problem with this approach?

I updated the manual, and don't think a NEWS entry is required.
Tested on x86_64-linux, with no regressions.

-- 
Daniel Jacobowitz
CodeSourcery

2009-11-23  Daniel Jacobowitz  <dan@codesourcery.com>

	* c-exp.y (yylex): Stop before "thread N".

	* gdb.texinfo (Thread-Specific Breakpoints): Thread specifiers
	are allowed after the breakpoint condition.

	* gdb.base/condbreak.exp: Test combinations of "break *EXP",
	"if", and "thread".  Correct matching in the previous test.

Index: c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.65
diff -u -p -r1.65 c-exp.y
--- c-exp.y	11 Nov 2009 16:45:46 -0000	1.65
+++ c-exp.y	23 Nov 2009 21:26:06 -0000
@@ -2250,6 +2250,22 @@ yylex (void)
       return 0;
     }
 
+  /* For the same reason (breakpoint conditions), "thread N"
+     terminates the expression.  "thread" could be an identifier, but
+     an identifier is never followed by a number without intervening
+     punctuation.  */
+  if (namelen == 6
+      && strncmp (tokstart, "thread", 6) == 0
+      && (tokstart[6] == ' ' || tokstart[6] == '\t')
+      && ! scanning_macro_expansion ())
+    {
+      char *p = tokstart + 7;
+      while (*p == ' ' || *p == '\t')
+	p++;
+      if (*p >= '0' && *p <= '9')
+	return 0;
+    }
+
   lexptr += namelen;
 
   tryname:
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.642
diff -u -p -r1.642 gdb.texinfo
--- doc/gdb.texinfo	23 Nov 2009 18:44:10 -0000	1.642
+++ doc/gdb.texinfo	23 Nov 2009 21:26:13 -0000
@@ -5214,8 +5214,8 @@ breakpoint, the breakpoint applies to @e
 program.
 
 You can use the @code{thread} qualifier on conditional breakpoints as
-well; in this case, place @samp{thread @var{threadno}} before the
-breakpoint condition, like this:
+well; in this case, place @samp{thread @var{threadno}} before or
+after the breakpoint condition, like this:
 
 @smallexample
 (@value{GDBP}) break frik.c:13 thread 28 if bartab > lim
Index: testsuite/gdb.base/condbreak.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/condbreak.exp,v
retrieving revision 1.13
diff -u -p -r1.13 condbreak.exp
--- testsuite/gdb.base/condbreak.exp	3 Jan 2009 05:58:03 -0000	1.13
+++ testsuite/gdb.base/condbreak.exp	23 Nov 2009 21:26:13 -0000
@@ -207,10 +207,10 @@ gdb_expect {
 setup_xfail hppa2.0w-*-* 11512CLLbs
 send_gdb "continue\n"
 gdb_expect {
-    -re "Continuing\\..*Breakpoint \[0-9\]+, marker2 \\(a=43\\) at .*$srcfile1:($bp_location8|$bp_location9).*($bp_location8|$bp_location9)\[\t \]+.*" {
+    -re "Continuing\\..*Breakpoint \[0-9\]+, marker2 \\(a=43\\) at .*$srcfile1:($bp_location8|$bp_location9).*($bp_location8|$bp_location9)\[\t \]+.*$gdb_prompt $" {
 	pass "run until breakpoint at marker2"
     }
-    -re "Continuing\\..*Breakpoint \[0-9\]+, $hex in marker2 \\(a=43\\) at .*$srcfile1:($bp_location8|$bp_location9).*($bp_location8|$bp_location9)\[\t \]+.*" {
+    -re "Continuing\\..*Breakpoint \[0-9\]+, $hex in marker2 \\(a=43\\) at .*$srcfile1:($bp_location8|$bp_location9).*($bp_location8|$bp_location9)\[\t \]+.*$gdb_prompt $" {
 	xfail "run until breakpoint at marker2"
     }
     -re "$gdb_prompt $" {
@@ -220,3 +220,16 @@ gdb_expect {
 	fail "(timeout) run until breakpoint at marker2"
     }
 }
+
+# Test combinations of conditional and thread-specific breakpoints.
+gdb_test "break main if (1==1) thread 999" \
+    "Unknown thread 999\\."
+gdb_test "break main thread 999 if (1==1)" \
+    "Unknown thread 999\\."
+
+# Verify that both if and thread can be distinguished from a breakpoint
+# address expression.
+gdb_test "break *main if (1==1) thread 999" \
+    "Unknown thread 999\\."
+gdb_test "break *main thread 999 if (1==1)" \
+    "Unknown thread 999\\."


             reply	other threads:[~2009-11-23 21:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 21:27 Daniel Jacobowitz [this message]
2009-11-24  0:21 ` Joel Brobecker
2009-11-24 10:33 ` Andrew Stubbs
2009-11-24 14:24   ` Daniel Jacobowitz
2009-11-24 14:54     ` Joel Brobecker
2009-11-24 15:05       ` Daniel Jacobowitz
2009-11-25 20:43         ` Daniel Jacobowitz
2009-12-01 19:53           ` Maciej W. Rozycki
2009-12-01 20:04             ` Daniel Jacobowitz
2010-01-01  6:31           ` [commit] Fix "break *EXP thread/task NUM" for Ada (was: "Re: RFC: Fix "break *EXP thread NUM"") Joel Brobecker
2009-11-24 17:08     ` RFC: Fix "break *EXP thread NUM" Tom Tromey

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=20091123212736.GA3828@caradoc.them.org \
    --to=drow@false.org \
    --cc=ams@codesourcery.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@codesourcery.com \
    --cc=vladimir@codesourcery.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