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]

[patch] sort multi-loc bpt; fixes mb-inline.exp false gdbindex FAIL


Hi,

with normal -> gdbindex run on x86_64-fedora18-linux-gnu one gets false FAIL:

-Breakpoint 1, foo (i=0) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
+Breakpoint 1, foo (i=1) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
 26       return i; // set breakpoint here^M
-(gdb) PASS: gdb.cp/mb-inline.exp: disabling location: run to breakpoint
+(gdb) FAIL: gdb.cp/mb-inline.exp: disabling location: run to breakpoint

due to:

 Num     Type           Disp Enb Address    What^M
 1       breakpoint     keep y   <MULTIPLE> ^M
-1.1                         y     0x080484ef in foo(int) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
-1.2                         y     0x0804848f in foo(int) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
+1.1                         y     0x0804848f in foo(int) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
+1.2                         y     0x080484ef in foo(int) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
 (gdb) PASS: gdb.cp/mb-inline.exp: info break
[...]
 disable 1.2^M
 (gdb) PASS: gdb.cp/mb-inline.exp: disabling location: disable
[...]
-Breakpoint 1, foo (i=0) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
+Breakpoint 1, foo (i=1) at gdb/testsuite/gdb.cp/mb-inline.h:26^M
 26       return i; // set breakpoint here^M
-(gdb) PASS: gdb.cp/mb-inline.exp: disabling location: run to breakpoint
+(gdb) FAIL: gdb.cp/mb-inline.exp: disabling location: run to breakpoint


One could make the testcase handle arbitrary address order but I find sorting
the addresses when multi-location breakpoint is created should not hurt
anything and it should be also more user convenient.

The wrong ordering happened during:

#1  in add_location_to_breakpoint (b=0x2234f00, sal=0x220c270) at breakpoint.c:8778
#2  in update_breakpoint_locations (b=0x2234f00, sals=..., sals_end=...) at breakpoint.c:13974
#3  in breakpoint_re_set_default (b=0x2234f00) at breakpoint.c:14166
#4  in bkpt_re_set (b=0x2234f00) at breakpoint.c:12885
#5  in breakpoint_re_set_one (bint=0x2234f00) at breakpoint.c:14266
#6  in catch_errors (func=0x6b36e6 <breakpoint_re_set_one>, func_args=0x2234f00, errstring=0x22656b0 "Error in re-setting breakpoint 1: ", mask=6) at exceptions.c:546
#7  in breakpoint_re_set () at breakpoint.c:14290


No regressions on {x86_64,x86_64-m32,i686}-fedora18-linux-gnu and with
gdbindex, where it fixes gdb.cp/mb-inline.exp.

Aware the gdbindex FAIL is not reliable as a real testcase for this fix.

I will check it in.


Thanks,
Jan


gdb/
2012-12-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* breakpoint.c (add_location_to_breakpoint): Insert the location with
	ADDRESS sorted.

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 40cceee..0826d13 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8770,9 +8770,12 @@ add_location_to_breakpoint (struct breakpoint *b,
   adjusted_address = adjust_breakpoint_address (loc_gdbarch,
 						sal->pc, b->type);
 
+  /* Sort the locations by their ADDRESS.  */
   loc = allocate_bp_location (b);
-  for (tmp = &(b->loc); *tmp != NULL; tmp = &((*tmp)->next))
+  for (tmp = &(b->loc); *tmp != NULL && (*tmp)->address <= adjusted_address;
+       tmp = &((*tmp)->next))
     ;
+  loc->next = *tmp;
   *tmp = loc;
 
   loc->requested_address = sal->pc;


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