Fix "list ambiguous_variable"
The "list" command allows specifying the name of variables as
argument, not just functions, so that users can type "list
a_global_variable".
That support is a broken when it comes to ambiguous locations though.
If there's more than one such global variable in the program, e.g.,
static globals in different compilation units, GDB ends up listing the
source of the first variable it finds, only.
linespec.c does find both symbol and minsym locations for all the
globals. The problem is that it ends up merging all the resulting
sals into one, because they all have address, zero. I.e., all sals
end up with sal.pc == 0, so maybe_add_address returns false for all
but the first.
The zero addresses appear because:
- in the minsyms case, linespec.c:minsym_found incorrectly treats all
minsyms as if they were function/text symbols. In list mode we can
end up with data symbols there, and we shouldn't be using
find_pc_sect_line on data symbols.
- in the debug symbols case, symbol_to_sal misses recording an address
(sal.pc) for non-block, non-label symbols.
gdb/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* linespec.c (minsym_found): Handle non-text minsyms.
(symbol_to_sal): Record a sal.pc for non-block, non-label symbols.
gdb/testsuite/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp (test_list_ambiguous_function):
Rename to ...
(test_list_ambiguous_symbol): ... this and add a symbol name
parameter. Adjust.
(test_list_ambiguous_function): Reimplement on top of
test_list_ambiguous_symbol and also test listing ambiguous
variables.
* gdb.base/list-ambiguous0.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.
* gdb.base/list-ambiguous1.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.