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.

1 files changed, 4 insertions, 1 deletions

diff --git a/gdb/linespec.c b/gdb/linespec.c
index 2f2a1a39104..019a9f80a3f 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);
 	}