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

[Luis Machado <luis.machado@linaro.org>]

Hi Andrew,

On 1/18/21 8:09 AM, Andrew Burgess wrote:
> * Luis Machado via Gdb-patches <gdb-patches@sourceware.org> [2021-01-14 09:50:42 -0300]:
> 
>> Hi,
>>
>> On 1/14/21 9:36 AM, Fredrik Hederstierna wrote:
>>> 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?
>>
>> The idea was to establish a common ground that could be used for both RISCV
>> and ARM, and prevent design issues from getting in the way.
>>
>> If RISCV bare metal corefile was merged, does that mean we can reuse the
>> same strategy to pursue bare metal ARM core file support now? And does that
>> mean we just need to come up with a patch using the same design?
> 
> We covered most of this ground in the discussion on the RISC-V patch,
> but if we assume that the plan is ELF + NOTES then most of the
> "design" is actually dictated by GDB and BFD already.  All we actually
> end up providing on the GDB side is glue to funnel the GDB state over
> to BFD.
> 
> Most of the work is in laying out the registers, something which is (I
> hope we can agree) something that is target specific.
> 
> My goal for this week is to get an updated revision of the RISC-V bare
> metal patches on to the list, with as much code as possible moved into
> a common file.  Honestly, I don't think there's going to be a huge
> amount of reuse, but I'll do as much as I can.

I'm sure you will. I can write some documentation based on my 
understanding so far. Maybe that will be a good start and then folks can 
add to it.


> 
> The ARM patch that was proposed was already ELF + NOTES, and already
> had some code in a common file.  So I'll probably borrow some of that.
> 
>>
>>> 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.
>>> And it would be really good if synergy could be used to share code, since alot functions I guess are same.
>>> If documentation is the issue, do we have an issue ticket on that?
>>
>>  From my end, the acceptance of ARM bare metal core files was dependent on
>> having a documented design of what the bare metal core files should look
>> like. Was that documentation included in the RISCV work? If not, that wasn't
>> the agreement when I send comments to that patch series.
> 
> The RISC-V work has not been merged, and writing some documentation is
> also on my goal list for this week.

That's what I noticed when I went looking for the commits. I think there 
was a misunderstanding.

> 
> I take all feedback I get on this list seriously, and though mistakes
> can happen, I'll not going to merge a patch without fixing the review
> issues, at least not without having a good discussion with the
> reviewer first.

No doubt about that, really. I think there was some expectation that 
merging changes into GDB was quicker than it really is in practice.

> 
> Thanks,
> Andrew
> 
>>
>>>
>>> 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'? It seems to be about to fail again if time just goes and none try push it further forward.
>>
>> I'd love to have such support, but I'm not actively working on it. I can
>> commit to review the changes and not let it be forgotten, but the
>> development work must be pursued by someone else.
> 
> 
> 
>>
>>>
>>> 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
>>>