diff options
author | Tom de Vries <tdevries@suse.de> | 2025-08-23 06:11:41 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2025-08-23 06:11:41 +0200 |
commit | 5a74ce37a50c8675ecfb10973eb1ec9139f36bd5 (patch) | |
tree | 659b55adffc15ecb3942efe48a1f724ba0ef1ce7 /gdb/doc/stack_frame.eps | |
parent | b0653e3db9c6d0d4f1f547e19aaad621aad58920 (diff) | |
download | binutils-5a74ce37a50c8675ecfb10973eb1ec9139f36bd5.zip binutils-5a74ce37a50c8675ecfb10973eb1ec9139f36bd5.tar.gz binutils-5a74ce37a50c8675ecfb10973eb1ec9139f36bd5.tar.bz2 |
[gdb/symtab] Bail out of create_addrmap_from_gdb_index on error
Currently, in create_addrmap_from_gdb_index, when finding an incorrect entry
in the address table of a .gdb_index section:
- a (by default silent) complaint is made,
- the entry is skipped, and
- the rest of the entries is processed.
This is the use-what-you-can approach, which make sense in general.
But in the case that the .gdb_index section is incorrect while the other debug
info is correct, this approach prevents gdb from building a correct cooked
index (assuming there's no bug in gdb that would cause an incorrect index to
be generated).
Instead, bail out of create_addrmap_from_gdb_index on finding errors in the
address table.
I wonder about the following potential drawback of this approach: in the case
that the .gdb_index section is incorrect because the debug info is incorrect,
this approach rejects the .gdb_index section and spents time rebuilding a
likewise incorrect index. But I'm not sure if this is a real problem.
Perhaps gdb will refuse to generate such an index, in which case this is a
non-issue.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/doc/stack_frame.eps')
0 files changed, 0 insertions, 0 deletions