aboutsummaryrefslogtreecommitdiff
path: root/gprof/po/rw.po
diff options
context:
space:
mode:
authorTom Tromey <tromey@redhat.com>2013-08-07 19:52:16 +0000
committerTom Tromey <tromey@redhat.com>2013-08-07 19:52:16 +0000
commitfdbb204be90dda0680acdf9b4829ddf531dc2aaa (patch)
tree1a4181f7d58eca02ef0a6c4559c35863cf043a10 /gprof/po/rw.po
parente44c37156491ae49e60796eb12b2d7c06ec04b07 (diff)
downloadgdb-fdbb204be90dda0680acdf9b4829ddf531dc2aaa.zip
gdb-fdbb204be90dda0680acdf9b4829ddf531dc2aaa.tar.gz
gdb-fdbb204be90dda0680acdf9b4829ddf531dc2aaa.tar.bz2
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.
Diffstat (limited to 'gprof/po/rw.po')
0 files changed, 0 insertions, 0 deletions