aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
diff options
context:
space:
mode:
authorKeith Seitz <keiths@redhat.com>2023-04-28 10:43:20 -0700
committerKeith Seitz <keiths@redhat.com>2023-04-28 10:43:20 -0700
commit1956da78cf450543343d58e5da9dc3cc6846dfff (patch)
tree7545f74a52ccca63db94fb62fce2ca5ab57fb84a /gdb/python
parent005b65e801c48344d82753c93db5436b310bfde4 (diff)
downloadbinutils-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