I am trying to debug an elf binary with a .gdb_index section, where gdb
The .gdb_index section has overlapping address ranges pointing to different
compile units, such as:
[0x100, 0x400) ==> cu_A,
[0x200, 0x300) ==> cu_B.
It seems that the implementation assumes a single compile unit for a given
address. When the user tries
to print a backtrace from a core file, it analyzes the wrong compile unit,
cannot find the range, and
has a gdb_assert failure:
static struct compunit_symtab *
data = ... addrmap_find ( ... ); // This returns a wrong result.
gdb_assert (result != NULL); // Fails here.
I am trying to understand whether this is a shortcoming of gdb, or
whether my .gdb_index section is hopelessly
corrupted. Can gdb_index address ranges contain such overlapping address
On Sat, 21 Dec 2019 05:00:42 +0100, Ali Tamur via gdb wrote:
> I am trying to understand whether this is a shortcoming of gdb, or
> whether my .gdb_index section is hopelessly
> corrupted. Can gdb_index address ranges contain such overlapping address
I do not think so but is your .gdb_index generated by GDB? Isn't it from gold?
You can try to regenerate it by GDB:
objcopy -R .gdb_index YOURFILE