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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Fredrik Hederstierna via Gdb-patches <gdb-patches@sourceware.org> [2021-01-14 12:36:35 +0000]:

> Ping, do anyone have any more input how to proceed on this?
> I think I have made what I can do, to the limits of my knowledge and understanding.
> 
> I read recently about RISCV now seems to have merged corefile
> support for their arch?

This is not correct, I posted some patches for RISC-V bare metal core
file support here:

  https://sourceware.org/pipermail/gdb-patches/2020-December/173714.html

They have not yet been merged.

> why can RISCV corefile be merged but not this? I guess ARM-Cortex
> users is magnitude amount higher and the benefit of this feature is
> huge.

Patches are not merged based on the popularity of a target, but on the
commitment of an engineer to see the patch merged.  You need to follow
up to review comments and convince other members of the list that the
patch is worth adding to GDB.

> And it would be really good if synergy could be used to share code,
> since alot functions I guess are same.

That requires people to do the work, right?

> If documentation is the issue, do we have an issue ticket on that?

You're welcome to create one.  Luis has made it clear he's going to
object to the patch until he sees some documentation.  If you want to
get your patch merged you either need to write the documentation,
convince someone else to write it, or convince Luis to drop that
requirement.  If you think having a ticket will help with any of the
above steps, then go for it.  But creating a ticket in itself doesn't
get the docs written.

> 
> Can we just merge this patch-v4 and set target GDB-11, and solve the
> doc-issue-ticket, then we just force ourselves to solve docs before
> the release, or how can we 'make it happen'?

The problem is nobody really wants to write documentation, so if we do
things that way, there's a pretty good chance the docs wont get
written.  Then either we (a) leave the feature in with no docs, or (b)
rip the feature out just to make some kind of point.

I think we should just decide up front if we are happy for it to be
undocumented, or write the docs.

>                                              It seems to be about to
> fail again if time just goes and none try push it further forward.

GDB is maintained with volunteer effort.  Nothing happens unless
someone wants to it happen.  So don't think of it as "failing",
instead think that if the patch stalls its simply a reflection that
demand for this feature is actually pretty low.

Thanks,
Andrew








> 
> Thanks! Kindly,
> Fredrik
> 
> From: Paul Mathieu <paulmathieu@google.com>
> Sent: Tuesday, October 27, 2020 5:53 PM
> To: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>
> Cc: Luis Machado <luis.machado@linaro.org>; Simon Marchi <simark@simark.ca>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>
> Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi 
>  
> Hi Fredrik,
> 
> > This is the current format when trying from ARM simulator:
> >
> > fredrik@legion ~/src/armv4t_coretest$ readelf -aA test.core
> > ELF Header:
> >   Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
> >   Class:                             ELF32
> >   Data:                              2's complement, little endian
> >   Version:                           1 (current)
> >   OS/ABI:                            ARM
> >   ABI Version:                       0
> >   Type:                              CORE (Core file)
> >   Machine:                           ARM
> >   Version:                           0x1
> >   Entry point address:               0x0
> >   Start of program headers:          52 (bytes into file)
> >   Start of section headers:          8084 (bytes into file)
> >   Flags:                             0x0
> >   Size of this header:               52 (bytes)
> >   Size of program headers:           32 (bytes)
> >   Number of program headers:         5
> >   Size of section headers:           40 (bytes)
> >   Number of section headers:         7
> >   Section header string table index: 6
> >
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
> >   [ 1] note0             NOTE            00000000 001e44 000138 00   A  0   0  1
> >   [ 2] load              PROGBITS        00010000 0000d4 000100 00  AX  0   0  1
> >   [ 3] load              PROGBITS        00080000 0001d4 000000 00  WA  0   0  1
> >   [ 4] load              PROGBITS        00080000 0001d4 000400 00  WA  0   0  1
> >   [ 5] load              PROGBITS        000fe790 0005d4 001870 00  WA  0   0  1
> >   [ 6] .shstrtab         STRTAB          00000000 001f7c 000016 00      0   0  1
> > Key to Flags:
> >   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
> >   L (link order), O (extra OS processing required), G (group), T (TLS),
> >   C (compressed), x (unknown), o (OS specific), E (exclude),
> >   y (purecode), p (processor specific)
> >
> > There are no section groups in this file.
> >
> > Program Headers:
> >   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >   NOTE           0x001e44 0x00000000 0x00000000 0x00138 0x00000 R   0x1
> >   LOAD           0x0000d4 0x00010000 0x00000000 0x00100 0x00100 R E 0x1
> >   LOAD           0x0001d4 0x00080000 0x00000000 0x00000 0x00000 RW  0x1
> >   LOAD           0x0001d4 0x00080000 0x00000000 0x00400 0x00400 RW  0x1
> >   LOAD           0x0005d4 0x000fe790 0x00000000 0x01870 0x01870 RW  0x1
> >
> >  Section to Segment mapping:
> >   Segment Sections...
> >    00
> >    01     load
> >    02     load
> >    03     load load
> >    04     load
> >
> > There is no dynamic section in this file.
> > There are no relocations in this file.
> > There are no unwind sections in this file.
> > No version information found in this file.
> >
> > Displaying notes found at file offset 0x00001e44 with length 0x00000138:
> >   Owner                 Data size       Description
> >   CORE                 0x0000007c       NT_PRPSINFO (prpsinfo structure)
> >   CORE                 0x00000094       NT_PRSTATUS (prstatus structure)
> 
> Does this support `.reg/xxx` notes for RTOS that support multiple tasks?
> It would be really nice to have `info threads` "just work"
> 
> Paul