[PATCH] gdb: add support for handling core dumps on arm-none-eabi
Luis Machado
luis.machado@linaro.org
Mon Oct 26 11:24:20 GMT 2020
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.
More information about the Gdb-patches
mailing list