diff options
author | Tom de Vries <tdevries@suse.de> | 2024-03-19 10:30:36 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2024-03-19 10:30:36 +0100 |
commit | 306361f0687a60b06503a2df3c0ba949afca215f (patch) | |
tree | da878fd1f0cf66da95035a8e424436c0c53c90f4 /include/opcode | |
parent | 97ce7870440d6b00181c2162ff5e56bb39b2e475 (diff) | |
download | binutils-306361f0687a60b06503a2df3c0ba949afca215f.zip binutils-306361f0687a60b06503a2df3c0ba949afca215f.tar.gz binutils-306361f0687a60b06503a2df3c0ba949afca215f.tar.bz2 |
[gdb] Further fix "value is not available" with debug frame
In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame")
I fixed a case in frame_unwind_register_value where using "set debug frame on"
caused an "info frame" command to abort, reporting a "value is not available"
error, due to the tpidruro register being unavailable.
Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from
non-FreeBSD target descriptions") removed the unavailable register, which
caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp.
While investigating the progression (see PR python/31437), I found that the
"debug frame" output of the test-case (when reverting commit bbb12eb9c84)
showed a smilar problem:
...
Python Exception <class 'gdb.error'>: value is not available^M
...
that was absent without "debug frame".
Fix this likewise in fetch_lazy_register, and update the test-case to check
for the exception.
Furthermore, I realized that there's both value::entirely_available and
value::entirely_unavailable, and that commit 2aaba744467 handled the case
of !entirely_available by printing unavailable.
Instead, print:
- "unavailable" for entirely_unavailable, and
- "partly unavailable" for !entirely_unavailable && !entirely_available.
Tested on x86_64-linux and arm-linux.
Diffstat (limited to 'include/opcode')
0 files changed, 0 insertions, 0 deletions