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

[Fredrik Hederstierna <fredrik.hederstierna@verisure.com>]

> 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.

Thanks! BR Fredrik