diff options
author | Andrew Burgess <aburgess@redhat.com> | 2022-12-12 14:05:22 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2022-12-16 13:51:08 +0000 |
commit | c3efaf0afd9d37004c42cdfd3ce0c1bfa979c45e (patch) | |
tree | e2b3eb1907fa8a3ad718dd0179881bc6d69d3a18 /gdb/testsuite/gdb.python/py-label-symbol-value.exp | |
parent | e60a615dde5d6674a6488b74afe807a775551407 (diff) | |
download | binutils-c3efaf0afd9d37004c42cdfd3ce0c1bfa979c45e.zip binutils-c3efaf0afd9d37004c42cdfd3ce0c1bfa979c45e.tar.gz binutils-c3efaf0afd9d37004c42cdfd3ce0c1bfa979c45e.tar.bz2 |
gdb: fix crash when getting the value of a label symbol
When the source program contains a goto label, it turns out it's
actually pretty hard for a user to find out more about that label.
For example:
(gdb) p some_label
No symbol "some_label" in current context.
(gdb) disassemble some_label
No symbol "some_label" in current context.
(gdb) x/10i some_label
No symbol "some_label" in current context.
(gdb) break some_label
Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.
In all cases, some_label is a goto label within the current frame.
Only placing a breakpoint on the label worked.
This all seems a little strange to me, it feels like asking about a
goto label would not be an unreasonable thing for a user to do.
This commit doesn't fix any of the above issues, I mention them just
to provide a little context for why the following issue has probably
not been seen before.
It turns out there is one way a user can access the symbol for a goto
label, through the Python API:
python frame = gdb.selected_frame()
python frame_pc = frame.pc()
python block = gdb.current_progspace().block_for_pc(frame_pc)
python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
python print(str(symbol.value()))
../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.
The problem is that label symbols are created using the
builtin_core_addr type, which is a pure integer type.
When GDB tries to fetch the value of a label symbol then we end up in
findvar.c, in the function language_defn::read_var_value, in the
LOC_LABEL case. From here store_typed_address is called to store the
address of the label into a value object with builtin_core_addr type.
The problem is that store_typed_address requires that the destination
type be a pointer or reference, which the builtin_core_addr type is
not.
Now it's not clear what type a goto label address should have, but
GCC has an extension that allows users to take the address of a goto
label (using &&), in that case the result is of type 'void *'.
I propose that when we convert the CORE_ADDR value to a GDB value
object, we use builtin_func_ptr type instead of builtin_core_addr,
this means the result will be of type 'void (*) ()'. The benefit of
this approach is that when gdbarch_address_to_pointer is called the
target type will be correctly identified as a pointer to code, which
should mean any architecture specific adjustments are done correctly.
We can then cast the new value to 'void *' type with a call to
value_cast_pointer, this should not change the values bit
representation, but will just update the type.
After this asking for the value of a label symbol works just fine:
(gdb) python print(str(symbol.value()))
0x401135 <main+35>
And the type is maybe what we'd expect:
(gdb) python print(str(symbol.value().type))
void *
Diffstat (limited to 'gdb/testsuite/gdb.python/py-label-symbol-value.exp')
-rw-r--r-- | gdb/testsuite/gdb.python/py-label-symbol-value.exp | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/gdb/testsuite/gdb.python/py-label-symbol-value.exp b/gdb/testsuite/gdb.python/py-label-symbol-value.exp new file mode 100644 index 0000000..44321e5 --- /dev/null +++ b/gdb/testsuite/gdb.python/py-label-symbol-value.exp @@ -0,0 +1,39 @@ +# Copyright 2022 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/>. + +# Check that GDB handles the user asking for the value of a label +# symbol (i.e. a symbol for a goto label). + +load_lib gdb-python.exp +standard_testfile + +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } { + return -1 +} + +# Skip all tests if Python scripting is not enabled. +if { [skip_python_tests] } { continue } + +if ![runto_main] { + return -1 +} + +# Use Python to print the value of the 'some_label' symbol. +gdb_test "python frame = gdb.selected_frame()" +gdb_test "python frame_pc = frame.pc()" +gdb_test "python block = gdb.current_progspace().block_for_pc(frame_pc)" +gdb_test "python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)" +gdb_test "python print(str(symbol.value()))" "$hex <main\\+$decimal>" +gdb_test "python print(str(symbol.value().type))" "void \\*" |