aboutsummaryrefslogtreecommitdiff
path: root/gdb/source.c
diff options
context:
space:
mode:
authorMaciej W. Rozycki <macro@embecosm.com>2023-02-10 23:49:19 +0000
committerMaciej W. Rozycki <macro@embecosm.com>2023-02-10 23:49:19 +0000
commitbae19789c0a2d4e88b5b441acebe4d9e1522cd67 (patch)
tree0e87db154b2957b716aa3a3432a95efdbccbaab6 /gdb/source.c
parent4a9efa5d63b2253a595ff9d6944415bf8cbfe408 (diff)
downloadgdb-bae19789c0a2d4e88b5b441acebe4d9e1522cd67.zip
gdb-bae19789c0a2d4e88b5b441acebe4d9e1522cd67.tar.gz
gdb-bae19789c0a2d4e88b5b441acebe4d9e1522cd67.tar.bz2
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element accesses cause an error for entries exceeding the currently selected `max-value-size' setting even where such accesses successfully complete for elements located in the inferior, e.g.: (gdb) p/d one $1 = 0 (gdb) p/d one_hundred $2 = {0 <repeats 100 times>} (gdb) p/d one_hundred[99] $3 = 0 (gdb) set max-value-size 25 (gdb) p/d one_hundred value requires 100 bytes, which is more than max-value-size (gdb) p/d one_hundred[99] $7 = 0 (gdb) p/d $2 value requires 100 bytes, which is more than max-value-size (gdb) p/d $2[99] value requires 100 bytes, which is more than max-value-size (gdb) According to our documentation the `max-value-size' setting is a safety guard against allocating an overly large amount of memory. Moreover a statement in documentation says, concerning this setting, that: "Setting this variable does not affect values that have already been allocated within GDB, only future allocations." While in the implementer-speak the sentence may be unambiguous I think the outside user may well infer that the setting does not apply to values previously printed. Therefore rather than just fixing this inconsistency it seems reasonable to lift the setting for value history accesses, under an implication that by having been retrieved from the debuggee they have already passed the safety check. Do it then, by suppressing the value size check in `value_copy' -- under an observation that if the original value has been already loaded (i.e. it's not lazy), then it must have previously passed said check -- making the last two commands succeed: (gdb) p/d $2 $8 = {0 <repeats 100 times>} (gdb) p/d $2 [99] $9 = 0 (gdb) Expand the testsuite accordingly, covering both value history handling and the use of `value_copy' by `make_cv_value', used by Python code.
Diffstat (limited to 'gdb/source.c')
0 files changed, 0 insertions, 0 deletions