This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
src/gdb ChangeLog linespec.c
- From: tromey at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: Wed, 07 Aug 2013 19:52:16 +0000
- Subject: 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