]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/value.c
GDB: Ignore `max-value-size' setting with value history accesses
authorMaciej W. Rozycki <macro@embecosm.com>
Fri, 10 Feb 2023 23:49:19 +0000 (23:49 +0000)
committerMaciej W. Rozycki <macro@embecosm.com>
Fri, 10 Feb 2023 23:49:19 +0000 (23:49 +0000)
commitbae19789c0a2d4e88b5b441acebe4d9e1522cd67
tree0e87db154b2957b716aa3a3432a95efdbccbaab6
parent4a9efa5d63b2253a595ff9d6944415bf8cbfe408
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.
gdb/testsuite/gdb.base/max-value-size.exp
gdb/testsuite/gdb.python/py-xmethods.exp
gdb/testsuite/gdb.python/py-xmethods.py
gdb/value.c