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

[Simon Marchi <simark@simark.ca>]

On 2020-10-16 8:02 p.m., Fredrik Hederstierna via Gdb-patches wrote:
> Hi
>
> I saw that recently there was new interest of corefile support for arm-none-eabi.

For others, Fredrik is referring to this other thread with the same subject:

  https://sourceware.org/pipermail/gdb-patches/2020-October/172258.html

In this other thread, we deviated from the main subject trying to figure
out how GDB can differentiate a Linux executable from a bare-metal
executable.  Maybe we can just ignore that for the moment and get
something simple but useful merged.  This problem won't occur if someone
is using a toolchain built with --target=arm-none-eabi.  And if GDB is
built with support for the Linux osabi, then the user will just need to
do "set osabi none" to override it.  It seems to me like it's better to
have that than no core support at all for arm-none-eabi.

> In the past I have tried to raise interest of this several times, but with limited success unfortunately,
> so I am happy that possible there could be an opening to get this support into GDB,
> and I would like to take to opportunity to also try push some more for GDB maintainers to try get support for this very useful feature.

Indeed, it's apparently something that comes up often, I'm all for
it.  Let's try to get it to work this time :).

> I already tried to push in the past for my own patch that also support eg floating-point support, and gcore etc.
> The patch is using linux core file format as starting point but has stripped out Linux specific parts.
>
> See
> https://sourceware.org/bugzilla/show_bug.cgi?id=14383
>
> The GDB verision at the time was GDB-7.11.1 so it may be out-of-date.
> (The post in mail-thread:  https://sourceware.org/pipermail/gdb/2014-September/044559.html)

I skimmed your patch, and I see that you implemented the
support for "generate-core-file", which is awesome.  It's one of the
comments I had on Paul's patch.

> If there is interest of adding this feature now, I could also try help to get this feature into GDB.
>
> I also believe that there is some need to 'formalize' the format, and my best idea so far is to try adding corefile to some popular 'bare metal' target RTOS.
> I've been thinking of defining a format for FreeRTOS, but basically being a bare-metal target.

I think it would make sense first to make GDB able to generate cores
(with generate-core-file) and consume them.  It makes it much easier to
test than if we have to rely on an external tool (plus, it's useful).

In theory, it should be able to generate a core while connected to the
GDB sim target, which means that everyone can do it, no special hardware
or tool required.

Once this is done, it should be easy to go to projects like FreeRTOS and
suggest adding things like that.

> The idea then is to have some PC host supporting tool to convert/generate corefiles from some custom memory dump formats.
> The FreeRTOS (or any other bare-metal alike OS) could maintain this supporting tool.

Indeed.

One question for you: when making GDB generate the core, I presume it
would always have a single thread, as when debugging a bare-metal ARM
processor with GDB, you see a single thread.

Assuming you make that tool to convert a memory dump of a FreeRTOS
system to a core GDB can read, would you make each FreeRTOS task appear
as a separate thread in the core?

> Here is one example what I investigated, a similar PC host conversion app that could possibly be basis of such tool, example:
> https://github.com/rogercollins/bare_core
>
> I think next step is to define/decide a format that would be accepted by GDB maintainers, eg FreeRTOS-bare-metal or something,
> then work in parallel with some supporting host PC tool, but maybe this should not be part of GDB itself?
> Any comments or ideas are most welcome!

As I said, I think the first logical step is to make GDB able to
generate cores and consume them.  The "Linux format minus the
Linux-specific parts" format sounds good to me, but you would need to
specify what are those Linux-specific parts that you removed, for
clarity.

Can you and Paul maybe sync up (and with Luis as well, probably) on what
are the next steps?  I think your patch was a great start, but it would
need to be rebased.  You could also look at Paul's patch to see if
there's anything you'd like to pick from it.

I'll be happy to give it a try with my NorthSec conference badge [1].
It runs a Cortex-M0 that we can debug using a Black Magic probe [2], so
I think it's a good real-life example.  Plus, I made it run FreeRTOS, so
it would be a good candidate for that too.

Simon

[1] https://montrehack.ca/images/19-09_nsec_badge.jpg
[2] https://github.com/blacksphere/blackmagic/wiki