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

[Alan Hayward via Gdb-patches <gdb-patches@sourceware.org>]

> On 19 Oct 2020, at 03:08, Simon Marchi <simark@simark.ca> 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 :).

+1

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

I would just add that arm_none_core_read_description will need updating
to use the newer tdesc code. Possibly identical to arm_linux_core_read_description.


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

I’d like to request the core file format is documented somewhere.

Best place I think would be in the GDB manual.
Probably by adding an arm-none section in G.5.3 ARM Features.

(no need to do this until something is agreed on though)

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