OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
binutils-gdb/gdb/testsuite/gdb.base/list-ambiguous.exp

80 lines
2.9 KiB
Plaintext
Raw Normal View History

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 17:49:29 +02:00
# Copyright 2017 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Test the "list" command with linespecs that expand to multiple
# locations.
standard_testfile list-ambiguous0.c list-ambiguous1.c
if {[prepare_for_testing "failed to prepare" $testfile [list $srcfile $srcfile2] \
{debug}]} {
return -1
}
# Build source listing pattern based on an inclusive line range.
proc line_range_pattern { range_start range_end } {
global line_re
for {set i $range_start} {$i <= $range_end} {incr i} {
append pattern "\r\n$i\[ \t\]\[^\r\n\]*"
}
verbose -log "pattern $pattern"
return $pattern
}
# Test the "list" command with linespecs that expand to multiple
# locations.
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 17:12:54 +02:00
proc test_list_ambiguous_symbol {symbol_line symbol} {
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 17:49:29 +02:00
global srcfile srcfile2
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 17:12:54 +02:00
set lineno0 [gdb_get_line_number $symbol_line $srcfile]
set lineno1 [gdb_get_line_number $symbol_line $srcfile2]
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 17:49:29 +02:00
set lines0_re [line_range_pattern [expr $lineno0 - 5] [expr $lineno0 + 4]]
set lines1_re [line_range_pattern [expr $lineno1 - 5] [expr $lineno1 + 4]]
set any "\[^\r\n\]*"
Make "list ambiguous" show symbol names too Currently, with an ambiguous "list first,last", we get: (gdb) list bar,main Specified first line 'bar' is ambiguous: file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97 file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98 This commit makes gdb's output above a bit clearer by printing the symbol name as well: (gdb) list bar,main Specified first line 'bar' is ambiguous: file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)" file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)" And while at it, makes gdb print the symbol name when actually listing multiple locations too. I.e., before (with "set listsize 2"): (gdb) list bar file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97 96 97 int bar (A) { return 11; } file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98 97 int bar (A) { return 11; } 98 int bar (B) { return 22; } After: (gdb) list bar file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)" 96 97 int bar (A) { return 11; } file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)" 97 int bar (A) { return 11; } 98 int bar (B) { return 22; } Currently, the result of decoding a linespec loses information about the original symbol that was found. All we end up with is an address. This makes it difficult to find the original symbol again to get at its print name. Fix that by storing a pointer to the symbol in the sal. We already store the symtab and obj_section, so it feels like a natural progression to me. This avoids having to do any extra symbol lookup too. gdb/ChangeLog: 2017-09-20 Pedro Alves <palves@redhat.com> * cli/cli-cmds.c (list_command): Use print_sal_location. (print_sal_location): New function. (ambiguous_line_spec): Use print_sal_location. * linespec.c (symbol_to_sal): Record the symbol in the sal. * symtab.c (find_function_start_sal): Likewise. * symtab.h (symtab_and_line::symbol): New field. gdb/testsuite/ChangeLog: 2017-09-20 Pedro Alves <palves@redhat.com> * gdb.base/list-ambiguous.exp (test_list_ambiguous_symbol): Expect symbol names in gdb's output. * gdb.cp/overload.exp ("list all overloads"): Likewise.
2017-09-20 17:12:54 +02:00
set h0_re "file: \"${any}list-ambiguous0.c\", line number: $lineno0, symbol: \"$symbol\""
set h1_re "file: \"${any}list-ambiguous1.c\", line number: $lineno1, symbol: \"$symbol\""
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 17:12:54 +02:00
gdb_test "list $symbol" "${h0_re}${lines0_re}\r\n${h1_re}${lines1_re}"
gdb_test "list main,$symbol" \
"Specified last line '$symbol' is ambiguous:\r\n${h0_re}\r\n${h1_re}"
gdb_test "list ,$symbol" \
"Specified last line '$symbol' is ambiguous:\r\n${h0_re}\r\n${h1_re}"
gdb_test "list $symbol,main" \
"Specified first line '$symbol' is ambiguous:\r\n${h0_re}\r\n${h1_re}"
gdb_test "list $symbol,$symbol" \
"Specified first line '$symbol' is ambiguous:\r\n${h0_re}\r\n${h1_re}"
gdb_test "list $symbol," \
"Specified first line '$symbol' is ambiguous:\r\n${h0_re}\r\n${h1_re}"
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 17:49:29 +02:00
# While at it, test the "edit" command as well, since it shares
# code with "list".
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 17:12:54 +02:00
gdb_test "edit $symbol" \
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 17:49:29 +02:00
"Specified line is ambiguous:\r\n${h0_re}\r\n${h1_re}"
}
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 17:12:54 +02:00
proc test_list_ambiguous_function {} {
test_list_ambiguous_symbol "ambiguous_fun (void)" "ambiguous_fun"
test_list_ambiguous_symbol "ambiguous_var" "ambiguous_var"
}
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 17:49:29 +02:00
gdb_test_no_output "set listsize 10"
test_list_ambiguous_function