From: Luis Machado <luis.machado@linaro.org>
To: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>,
Paul Mathieu <paulmathieu@google.com>
Cc: 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
Date: Thu, 14 Jan 2021 09:50:42 -0300 [thread overview]
Message-ID: <ca251409-1c90-641b-16f8-392fe74719aa@linaro.org> (raw)
In-Reply-To: <HE1PR10MB1723176DFC807A27672B332EEFA80@HE1PR10MB1723.EURPRD10.PROD.OUTLOOK.COM>
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?
> 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.
>
> 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
>
next prev parent reply other threads:[~2021-01-14 12:50 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 0:02 Fredrik Hederstierna
2020-10-19 2:08 ` Simon Marchi
2020-10-19 13:13 ` Luis Machado
2020-10-19 13:15 ` Alan Hayward
2020-10-19 15:25 ` Paul Mathieu
2020-10-20 11:41 ` Fredrik Hederstierna
2020-10-20 12:39 ` Simon Marchi
2020-10-20 14:00 ` Fredrik Hederstierna
2020-10-20 15:04 ` Simon Marchi
2020-10-20 22:05 ` Fredrik Hederstierna
2020-10-20 23:06 ` Simon Marchi
2020-10-22 0:52 ` Fredrik Hederstierna
2020-10-22 1:24 ` Simon Marchi
2020-10-22 1:49 ` Simon Marchi
2020-10-22 22:32 ` Fredrik Hederstierna
2020-10-23 0:37 ` Simon Marchi
2020-10-25 21:06 ` Fredrik Hederstierna
2020-10-26 11:24 ` Luis Machado
2020-10-26 15:49 ` Fredrik Hederstierna
2020-10-27 16:53 ` Paul Mathieu
2021-01-14 12:36 ` Fredrik Hederstierna
2021-01-14 12:50 ` Luis Machado [this message]
2021-01-18 11:09 ` Andrew Burgess
2021-01-18 14:01 ` Luis Machado
2021-06-21 6:30 ` [PATCH] sim: arm: add support for handling core dumps Fredrik Hederstierna
2021-06-22 3:20 ` Mike Frysinger
2021-06-24 13:01 ` Alan Hayward
2021-06-29 9:11 ` Fredrik Hederstierna
2021-01-18 11:01 ` [PATCH] gdb: add support for handling core dumps on arm-none-eabi Andrew Burgess
2021-06-22 2:16 ` Mike Frysinger
2020-10-20 19:34 ` [PATCH] gdb: Support corefiles for arm-none-eabi Fredrik Hederstierna
2020-10-20 21:49 ` Fredrik Hederstierna
2020-10-20 21:58 ` [PATCH v2] Support for corefiles for arm-none-eabi target Fredrik Hederstierna
2020-10-21 2:51 ` Simon Marchi
2020-10-21 14:38 ` Luis Machado
2020-10-22 0:44 ` [PATCH v3][PR gdb/14383]: gdb: corefile support " Fredrik Hederstierna
2020-10-22 0:44 ` [PATCH v3][PR gdb/14383]: Support for corefiles " Fredrik Hederstierna
2020-10-25 20:46 ` [PATCH] " Fredrik Hederstierna
2020-10-25 20:50 ` [PATCH v4][PR gdb/14383] " Fredrik Hederstierna
-- strict thread matches above, loose matches on Subject: below --
2020-10-02 17:32 [PATCH] gdb: add support for handling core dumps on arm-none-eabi Paul Mathieu
2020-10-02 17:51 ` Luis Machado
2020-10-02 21:54 ` Paul Mathieu
2020-10-02 21:59 ` Simon Marchi
2020-10-03 3:57 ` Simon Marchi
2020-10-02 23:55 ` Simon Marchi
2020-10-03 0:35 ` Paul Mathieu
2020-10-03 2:24 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca251409-1c90-641b-16f8-392fe74719aa@linaro.org \
--to=luis.machado@linaro.org \
--cc=fredrik.hederstierna@verisure.com \
--cc=gdb-patches@sourceware.org \
--cc=paulmathieu@google.com \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).