Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi

[Luis Machado <luis.machado@linaro.org>]

On 10/25/20 6:06 PM, Fredrik Hederstierna via Gdb-patches wrote:
>> From: Simon Marchi <simark@simark.ca>
>> Sent: Friday, October 23, 2020 2:37 AM
>>
>> On my side, from the comments I gave earlier and other observations:
>>
>> - there area clearly some unnecessary includes, cut it down to what's
>>   necessary
>> - don't put things in the header file if they are only used in the
>>    source file (the macros in arm-none-tdep.h, for example)
>> - none_init_corefile has an unused parameter
>> - some unnecessary forward declarations here and there
>> - is the handling of inferior arguments relevant for bare-metal?
>> - if it works with the GDB simulator (target sim), I'd really like if we
>>    could have a test for this: generate a core, read it back, make sure
>>    you can print stuff
> 
> Thanks for feedback, I think the new [Patch v4] address all your bullets above.
> 
> I have tested the patch on ARM simulator in GDB, and it worked,
> though some observations:
> 
> - The ARM simulator does not support ARM Cortex architecture?
>    I had to try it out on ARMv4T arch code, though needed to make some patchwork.
> - The ARM simulator does enumerate registers differently, and remapping is done,
> though if trying to fetch all registers by passing -1, then eg D0-D15 was not handled.
> - The ARM simulator expect that target have a stack frame and tried to put that in separate section,
>    though this needs to be setup, if just running with SP=0, then SP will soon be 0xFFFFFFFxx, and
>    then when trying to make corefile and stack should be saved, all 0-0xFFFFFFFFF will be saved 4GByte!
>    Though by explicitly setting SP (either by code or from console) it seems to work.
>    Cortex handles initial stack pointer differently by having an entry for SP in start vectors table.
> 
> This worked for me in the ARM simulator on test application compiled for ARMv4T thumb.
> 
> (gdb) target sim
> (gdb) load
> (gdb) break main
> (gdb) run
> (gdb) set $sp = 0xFFFFFF
> (gdb) cont
> <CTRL-C>
> (gdb) gcore test.core
> 
> Exiting and restarting GDB with elf-file and adding corefile 'test.core', same registers and call-stack could be reviewed, so my simple example worked.
> 
>> Luis and Alan (both GDB ARM maintainers) also expressed the desire to
>> have the format documented.  Alan suggested a section in the GDB manual,
>> in the ARM-specific section.  I think it is a good idea.  This is
>> important, so we have something to point to when people ask "what format
>> should I generate so GDB can read it".
> 
> Yes, it was suggested by someone to adding an arm-none section in "G.5.3 ARM Features".
> How to proceed on this? I guess the current design is same as *ix minus all specific *ix parts that could be stripped out from documentation.

I recall also suggesting discussing the core file format out in the open 
through the gdb@sourcware.org mailing list (here 
https://sourceware.org/pipermail/gdb-patches/2020-October/172721.html). 
That would make it easier to others interested in this to contribute and 
provide their thoughts.

It makes it a bit harder to design things based on patches directly.