Commit Graph

2 Commits

Author SHA1 Message Date
Pedro Alves e5f25bc5d6 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.
2017-09-20 16:12:54 +01:00
Pedro Alves e439fa140a Clarify "list" output when specified lines are ambiguous
Currently, with "list LINESPEC1,LINESPEC2", if one of the linespecs is
ambiguous, i.e., if it expands to multiple locations, you get this
seemingly odd output:

 (gdb) list foo,bar
 file: "file0.c", line number: 26
 file: "file1.c", line number: 29

Since "foo" above expands to multiple locations, the specified range
is indeterminate, and GDB is trying to be helpful by showing you what
was ambiguous.  It looks confusing to me, though.  I think it'd be
much more user friendly if GDB actually told you that, like this:

 (gdb) list foo,bar
 Specified first line 'foo' is ambiguous:
 file: "file0.c", line number: 26
 file: "file1.c", line number: 29

 (gdb) list bar,foo
 Specified last line 'foo' is ambiguous:
 file: "file0.c", line number: 26
 file: "file1.c", line number: 29

Note, I'm using "first" and "last" in the output because that's what
the manual uses:

 ~~~
 list first,last

     Print lines from first to last. [...]
 ~~~

Tested on x86-64 GNU/Linux.

gdb/ChangeLog:
2017-09-04  Pedro Alves  <palves@redhat.com>

	* cli/cli-cmds.c (edit_command): Pass message to
	ambiguous_line_spec.
	(list_command): Pass message to ambiguous_line_spec.  Say
	"first"/"last" instead of "start" and "end" to be consistent with
	the manual.
	(ambiguous_line_spec): Add 'format' and vararg parameters.  Use
	them to print formatted message.

gdb/testsuite/ChangeLog:
2017-09-04  Pedro Alves  <palves@redhat.com>

	* gdb.base/list-ambiguous.exp: New file.
	* gdb.base/list-ambiguous0.c: New file.
	* gdb.base/list-ambiguous1.c: New file.
	* gdb.base/list.exp (test_list_range): Adjust expected output.
2017-09-04 16:49:29 +01:00