diff options
author | Keith Seitz <keiths@redhat.com> | 2023-04-28 10:43:20 -0700 |
---|---|---|
committer | Keith Seitz <keiths@redhat.com> | 2023-04-28 10:43:20 -0700 |
commit | 1956da78cf450543343d58e5da9dc3cc6846dfff (patch) | |
tree | 7545f74a52ccca63db94fb62fce2ca5ab57fb84a /gdb/python | |
parent | 005b65e801c48344d82753c93db5436b310bfde4 (diff) | |
download | binutils-1956da78cf450543343d58e5da9dc3cc6846dfff.zip binutils-1956da78cf450543343d58e5da9dc3cc6846dfff.tar.gz binutils-1956da78cf450543343d58e5da9dc3cc6846dfff.tar.bz2 |
Allow strings with printf/eval
PR 13098 explains that if a user attempts to use a string with either
`printf' (or `eval'), gdb returns an error (inferior not running):
(gdb) printf "%s\n", "hello"
evaluation of this expression requires the target program to be active
However, the parser can certainly handle this case:
(gdb) p "hello"
$1 = "hello"
This discrepancy occurs because printf_c_string does not handle
this specific case. The passed-in value that we are attempting to print
as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.
printf_c_string will only attempt to print a string from the value's
contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
type is considered a string type:
if (value->type ()->code () != TYPE_CODE_PTR
&& value->lval () == lval_internalvar
&& c_is_string_type_p (value->type ()))
{
...
}
Otherwise, it attempts to read the value of the string from the target's
memory (which is what actually generates the "evaluation of this ..."
error message).
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions