This is the mail archive of the gdb-cvs@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]

src/gdb ChangeLog linespec.c


CVSROOT:	/cvs/src
Module name:	src
Changes by:	tromey@sourceware.org	2013-08-07 19:52:16

Modified files:
	gdb            : ChangeLog linespec.c 

Log message:
	also filter label symbols
	
	The bug here is that, with dwz -m, a function (and a label) appear in
	both a PU and a CU when running cplabel.exp.  So, a breakpoint gets
	two locations:
	
	(gdb) break foo::bar:to_the_top
	Breakpoint 2 at 0x400503: foo::bar:to_the_top. (2 locations)
	
	What is especially wacky is that both locations are at the same place:
	
	(gdb) info b
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   <MULTIPLE>
	1.1                         y     0x000000000040051c foo::bar:get_out_of_here
	1.2                         y     0x000000000040051c foo::bar:get_out_of_here
	
	This happens due to the weird way we run "dwz -m".
	It's unclear to me that this would ever happen for real code.
	
	While I think this borders on "diminishing returns" territory, the fix
	is pretty straightforward: use the existing address-filtering function
	in linespec to also filter when looking at labels.
	
	Built and regtested (both ways) on x86-64 Fedora 18.
	
	* linespec.c (convert_linespec_to_sals): Use maybe_add_address
	when adding label symbols.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15868&r2=1.15869
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/linespec.c.diff?cvsroot=src&r1=1.186&r2=1.187


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