This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Fix crash when loading a core with unexpected register section size
Pedro Alves writes:
> On 01/26/2017 02:59 PM, Antoine Tremblay wrote:
>>>> Ho yes, see v2, I added "For example arch-arm." Like you suggested.
>>> Eh, "arch-" in "arch-foo" was just meant to show I was talking
>>> about an arch. I didn't mean for you to keep the "arch-" part. :-)
>> hehe I figured but wasn't sure. I'll just say arm.
> The right name is uppercase "ARM". ;-)
Right right :)
>>> So basically, we could have a testcase that dumps a file, and then
>>> loads with back with no executable loaded? Do we really not
>>> have such a testcase yet?
>> Not exactly if it was that simple it would have been catched by
>> The problem is that this triggers only if the core file register section
>> is larger than expected. And if you just create a core and read it the
>> register section is ok.
>> However crafting a core with this problem is non-trivial at least to my
>> current knowledge.
> This is all information that would have been very handy to have
> in the submission upfront. Please put it in the commit log.
> OK with that change.
> One piece of info missing is why didn't GDB figure out this is
> a Linux core anyway, assuming it's a Linux core dump.
> I think the answer is that there's no ".note.ABI-tag"/NT_GNU_ABI_TAG
> section/note in core dumps. I think we could teach
> generic_elf_osabi_sniff_abi_tag_sections about detecting
> presence of ".note.linuxcore" sections:
> $ objdump -h ./testsuite/core.7452
> 3 .note.linuxcore.siginfo/7452 00000080 0000000000000000 0000000000000000 0000075c 2**2
> And then we'd end up with a gdbarch that has
> arm_linux_iterate_over_regset_sections installed, and thus no
Quite interesting, I'll investigate that and see if we can submit an
improvement along those lines. Thanks!