With the default APP_RETRIEVE_LEN_ELF_SHA setting, core dump files only have a
truncated ELF SHA256 in them. Account for this when comparing the core dump SHA
with the app ELF SHA.
The comment says it returns the "SHA256 hash of the input ELF file", but this is
not true - it was the SHA256 hash of the output ELF file. As the parser may
change some bytes around in minor ways, these were often not the same.
The check that the app ELF file SHA256 matches the one stored in the core dump
would never fail, leading to gdb loading the wrong ELF file and either crashing
or producing misleading debug information.
Specifics:
The note_sec.name field was incorrectly read back as b'ESP_CORE_DUMP_INFO\x00E',
because the namesz length includes the terminating NUL byte and possible junk
padding bytes:
https://github.com/espressif/esp-idf/blob/master/components/espcoredump/src/core_dump_elf.c#L212
In addition, as 'note_sec.name' is a bytes object Python 3 would have never
successfully compared it with a string.
- elf.py: elf related structs
- gdb.py: gdb related functions
- loader.py: extract elf/bin from flash to elf format core file
- xtensa.py: xtensa arch target related structs and functions
