Re: [PATCH] Fix crash when loading a core with unexpected register section size

[Pedro Alves <palves@redhat.com>]

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".  ;-)

>> 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
> gdb.base/corefile.exp
> 
> 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
crash.

But we shouldn't crash if NT_SIGINFO notes are missing, so
the patch is OK as is.

Thanks,
Pedro Alves