Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support

[Fredrik Hederstierna via Gdb-patches <gdb-patches@sourceware.org>]

> From: Paul Mathieu <paulmathieu@google.com>
> Sent: Monday, December 7, 2020 8:51 PM
> To: Luis Machado <luis.machado@linaro.org>
> Cc: Andrew Burgess <andrew.burgess@embecosm.com>; binutils@sourceware.org <binutils@sourceware.org>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Fredrik Hederstierna <fredrik.hederstierna@verisure.com>
> Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support 
> 
> Thanks Luis for getting the ball rolling again!
> 
> As far as I'm concerned, I haven't deployed much infrastructure to
> generate or otherwise deal with bare metal cores at the moment, so I'm
> happy to work with anything. The one thing that is a big deal to me is
> support for RTOS threads.
> 
> ELF + NOTES seems like the obvious choice to me, as it matches what
> I'm used to. Most online resources about core dumps seem to be
> specifically about Linux core dumps, so it would be less surprising
> and more helpful to share as much as possible with it, IMO.
> 
> What I'm expecting from a bare metal core dump:
> - memory dump sections
> - CPU registers
> - when available (RTOS support from the dumping side): inactive
> threads' CPU registers

Thanks all, good to see that bare metal corefile support involves even more people,  and increased interest to get gdb support this feature.
I'm sorry I haven't had much time this fall to put more time into it. The v4-patch as discussed here is my latest proposal, and as I understood it was some 'leftovers' yet regarding specification/documentation, but I had not good idea how to start this work, so I think I would need to some help where to start off.

Hopefully the more generic parts of the v4-patch like the 'none-tdep.c' parts could be reused by riscv, the it can open paths to make the future ARM-support less work and easier to get it done. Then hopefully the riscv documentation parts could be very similar and also could be possibly reused for the ARM corefile format.

Anything that could help the arm-none-corefile support is great, nice if these patches for arm and riscv do not diverge, better if the patches could 'help each other' to get a good solution as generic as possible, also opening paths for future corefiles for even other CPU architectures.
Can I do anything right now to help proceeding this process, I'm sorry I do not really know what I can do currently to 'make it happen' :-)

Thanks all, Best Regards,
Fredrik