aboutsummaryrefslogtreecommitdiff
path: root/ltsugar.m4
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2018-07-25 17:33:08 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2018-08-09 17:17:35 +0100
commit5ff2bbae198cbd615885f26aa7d065b8cec8c278 (patch)
tree297f0a5f275af87c325951d2ad818e8ba8d1e05b /ltsugar.m4
parente5bbcd0f04911d671d0c43d57df9886c06018705 (diff)
downloadgdb-5ff2bbae198cbd615885f26aa7d065b8cec8c278.zip
gdb-5ff2bbae198cbd615885f26aa7d065b8cec8c278.tar.gz
gdb-5ff2bbae198cbd615885f26aa7d065b8cec8c278.tar.bz2
gdb: Check element of optimised out vla exists
If a vla is not in memory, and the upper bound is not defined, then we can't know that an array element exists or not, and we should not try to access the array element. One case where this happens is for arrays that have been optimised out, the array will then have VALUE_LVAL of not_lval, and an undefined upper bound, if we then try to access an element of this array we will index into random GDB memory. An argument could be made that even for arrays that are in inferior memory, if the upper bound is not defined then we should not try to access the array element, however, in some of the Fortran tests, it seems as though we do rely indexing from a base address into an array which has no bounds defined. In this case GDBs standard protection for detecting unreadable target memory prevents bad thing happening. gdb/ChangeLog: * valarith.c (value_subscripted_rvalue): If an array is not in memory, and we don't know the upper bound, then we can't know that the requested element exists or not. gdb/testsuite/ChangeLog: * gdb.base/vla-optimized-out.exp: Add new test.
Diffstat (limited to 'ltsugar.m4')
0 files changed, 0 insertions, 0 deletions