This is the mail archive of the gdb-patches@sourceware.org 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]

Breakpoints can not be duplicates of tracepoints, period.


This fixes a class of problems that I think appeared when tracepoints
were made a kind of breakpoint a while ago.

Although it is possible (and desirable) to have multiple (high-level) 
breakpoints set at the same address, GDB still only inserts one
low-level breakpoint (e.g., trap) in the target for a given address.

But, is there's a tracepoint and a breakpoint set at the same address,
the target needs to know about both, so that when that location is
reached, it can both do tracepoint collection, and then report
the breakpoint hit to GDB.

Problem is, presently, gdb _is_ wrongly considering that breakpoints
can be duplicates of tracepoints.

Put in example form, the most obvious consequence, as explained above
is that with:

(gdb) trace foo
...
(gdb) break foo
...
(gdb) tstart
...
(gdb) c
...

The breakpoint at foo is never "hit".

Other examples are "next" or other commands that rely on internal
breakpoints losing control of the inferior.  The problem is
particularly easy to trigger with "next".  E.g.,

 (gdb) info trace
 Num     Type           Disp Enb Address    What
 1       breakpoint     keep y   0x08048485 in main at a.cc:3
 2       tracepoint     keep y   0x08048491 in main at a.cc:4
 (gdb) c
 Continuing.

 Breakpoint 1, main () at a.cc:3
 3           printf("Running TracepointTest App\n");
 (gdb) n

 Program exited normally.

Note that the tracepoint as set at line 4, while the breakpoint
at line 3.  The tracepoint is set at the address of the
step-resume breakpoint that "next" uses internally, and since
GDB has never set the breakpoint request to the target...

Multiple tracepoints at the same address shouldn't also be
duplicates of each other, since each of those can have its
own action list, etc.

Hence the patch below.

2010-02-12  Pedro Alves  <pedro@codesourcery.com>

	* breakpoint.c (allocate_bp_location): Use bp_loc_other for
	bp_tracepoint and bp_fast_tracepoint, not
	bp_loc_software_breakpoint.
	(update_global_location_list): Tracepoints are never duplicates of
	anything.

I've applied it.

-- 
Pedro Alves

---
 gdb/breakpoint.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: src/gdb/breakpoint.c
===================================================================
--- src.orig/gdb/breakpoint.c	2010-02-12 00:45:43.000000000 +0000
+++ src/gdb/breakpoint.c	2010-02-12 00:58:27.000000000 +0000
@@ -4812,8 +4812,6 @@ allocate_bp_location (struct breakpoint 
   switch (bpt->type)
     {
     case bp_breakpoint:
-    case bp_tracepoint:
-    case bp_fast_tracepoint:
     case bp_until:
     case bp_finish:
     case bp_longjmp:
@@ -4838,6 +4836,8 @@ allocate_bp_location (struct breakpoint 
       break;
     case bp_watchpoint:
     case bp_catchpoint:
+    case bp_tracepoint:
+    case bp_fast_tracepoint:
       loc->loc_type = bp_loc_other;
       break;
     default:
@@ -8575,7 +8575,8 @@ update_global_location_list (int should_
 	  || b->enable_state == bp_startup_disabled
 	  || !loc->enabled
 	  || loc->shlib_disabled
-	  || !breakpoint_address_is_meaningful (b))
+	  || !breakpoint_address_is_meaningful (b)
+	  || tracepoint_type (b))
 	continue;
 
       /* Permanent breakpoint should always be inserted.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]