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

[Luis Machado]

Hi Simon, Fredrik,

As was discussed in a private thread, it would be ideal for you 
(Fredrik) and Paul to sync things up and have a draft of a format that 
works for both, then we can go back to trying to fit it in GDB.

I'm guessing we'll want to make it generic enough to accomodate other 
architectures etc, just like the Linux core file format.

Alan and I can provide some feedback from ARM's side, and others can 
chime in for other architectures if needed.

If you'd like to discuss the format itself, I guess the gdb@ mailing 
list would be the place to have a chat before we turn it into a proper 
patch.

On 10/18/20 11:08 PM, Simon Marchi wrote:
> 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
>