diff options
author | Maciej W. Rozycki <macro@embecosm.com> | 2023-02-10 23:49:19 +0000 |
---|---|---|
committer | Maciej W. Rozycki <macro@embecosm.com> | 2023-02-10 23:49:19 +0000 |
commit | aaab5fce4f25e0d3b1a85edc7d6ac8f7d06f599c (patch) | |
tree | 27e8bf3de78fc774e0318806087240c8dffd86ac /multilib.am | |
parent | 4f82620cc9fd1ef630b6b732a9d939d4e529a07f (diff) | |
download | gdb-aaab5fce4f25e0d3b1a85edc7d6ac8f7d06f599c.zip gdb-aaab5fce4f25e0d3b1a85edc7d6ac8f7d06f599c.tar.gz gdb-aaab5fce4f25e0d3b1a85edc7d6ac8f7d06f599c.tar.bz2 |
GDB: Only make data actually retrieved into value history available
While it makes sense to allow accessing out-of-bounds elements in the
debuggee and see whatever there might happen to be there in memory (we
are a debugger and not a programming rules enforcement facility and we
want to make people's life easier in chasing bugs), e.g.:
(gdb) print one_hundred[-1]
$1 = 0
(gdb) print one_hundred[100]
$2 = 0
(gdb)
we shouldn't really pretend that we have any meaningful data around
values recorded in history (what these commands really retrieve are
current debuggee memory contents outside the original data accessed,
really confusing in my opinion). Mark values recorded in history as
such then and verify accesses to be in-range for them:
(gdb) print one_hundred[-1]
$1 = <unavailable>
(gdb) print one_hundred[100]
$2 = <unavailable>
Add a suitable test case, which also covers integer overflows in data
location calculation.
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'multilib.am')
0 files changed, 0 insertions, 0 deletions