From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2362 invoked by alias); 7 Aug 2013 19:45:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2327 invoked by uid 89); 7 Aug 2013 19:45:07 -0000 X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 07 Aug 2013 19:45:07 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r77Jj0R0019393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Aug 2013 15:45:00 -0400 Received: from barimba.redhat.com (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r77JixLa013380; Wed, 7 Aug 2013 15:44:59 -0400 From: Tom Tromey To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH v2 1/5] also filter label symbols Date: Wed, 07 Aug 2013 19:45:00 -0000 Message-Id: <1375904695-27787-2-git-send-email-tromey@redhat.com> In-Reply-To: <1375904695-27787-1-git-send-email-tromey@redhat.com> References: <1375904695-27787-1-git-send-email-tromey@redhat.com> X-SW-Source: 2013-08/txt/msg00211.txt.bz2 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 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. --- gdb/ChangeLog | 5 +++++ gdb/linespec.c | 5 ++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 975d2c5..3e50dff 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2013-02-04 Tom Tromey + + * linespec.c (convert_linespec_to_sals): Use maybe_add_address + when adding label symbols. + 2013-08-05 Tom Tromey * aix-thread.c (_initialize_aix_thread): Use diff --git a/gdb/linespec.c b/gdb/linespec.c index 2f2a1a3..019a9f8 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -1996,7 +1996,10 @@ convert_linespec_to_sals (struct linespec_state *state, linespec_p ls) for (i = 0; VEC_iterate (symbolp, ls->labels.label_symbols, i, sym); ++i) { - if (symbol_to_sal (&sal, state->funfirstline, sym)) + struct program_space *pspace = SYMTAB_PSPACE (SYMBOL_SYMTAB (sym)); + + if (symbol_to_sal (&sal, state->funfirstline, sym) + && maybe_add_address (state->addr_set, pspace, sal.pc)) add_sal_to_sals (state, &sals, &sal, SYMBOL_NATURAL_NAME (sym), 0); } -- 1.8.1.4