From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>,
binutils@sourceware.org, gdb-patches@sourceware.org,
Paul Mathieu <paulmathieu@google.com>
Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support
Date: Mon, 7 Dec 2020 14:24:33 -0300 [thread overview]
Message-ID: <615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org> (raw)
In-Reply-To: <20201207165836.GM2729@embecosm.com>
On 12/7/20 1:58 PM, Andrew Burgess wrote:
> * Luis Machado <luis.machado@linaro.org> [2020-12-07 12:58:19 -0300]:
>
>> On 12/7/20 12:17 PM, Andrew Burgess wrote:
>>> * Luis Machado <luis.machado@linaro.org> [2020-12-02 15:12:26 -0300]:
>>>
>>>> CC-ing paulmathieu@google.com and fredrik.hederstierna@verisure.com, who
>>>> were also looking into supporting bare metal ARM core files.
>>>>
>>>> Just a quick note...
>>>>
>>>> Back in October we pondered about this and it looked reasonable, at the
>>>> time, to put some effort into documenting the format (unlike the current
>>>> Linux core file format, which lacks good documentation).
>>>>
>>>> My take on it is that we need to settle on a format that works for multiple
>>>> architectures.
>>>
>>> Hi Luis,
>>>
>>> Thanks for your feedback, I'd love to better understand what you are
>>> proposing here.
>>
>> Sure. What I'm proposing here is the same I proposed in this thread about
>> ARM bare metal core files...
>>
>> https://sourceware.org/pipermail/gdb-patches/2020-October/172617.html
>>
>> ... and also suggested by Simon here:
>>
>> https://sourceware.org/pipermail/gdb-patches/2020-October/172270.html
>>
>> In summary, we should document what a bare metal core file is, what pieces
>> it is expected to contain (registers, target descriptions, hardware
>> information, execution environment etc) and what format it will be in.
>>
>>>
>>> Could you expand a little on why we need a format that supports
>>> multiple architectures (i.e. what benefits will this bring)? And how
>>> this would be different to the approach taken here
>>
>> Having a common format makes it easier to maintain the code and expand the
>> features when needed. This is not different from the Linux core file we have
>> today. The Linux core file is a common format.
>>
>> But unlike Linux core files, which have less than ideal documentation and
>> specifications, we want to take this opportunity to start clean and to
>> document everything required to have a proper bare metal core file.
>>
>> I think this initial definition and documentation will benefit developers
>> moving forward.
>>
>> Does that make it more clear?
>
> Not really. I'll go read the various threads that you referenced and
> see come back once I have more specific questions.
>
> Thanks for the pointers.
>
> Andrew
>
I'm sorry that did not clarify things, but there isn't much more than
that really. All I'm suggesting (up to you to accept it) is that we
clarify/coordinate with the interested parties on what is needed for
bare metal core files and document it properly (I don't think code is
proper documentation).
Clearly there are more folks interested in this.
next prev parent reply other threads:[~2020-12-07 17:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 17:39 [PATCH 0/8] Bare-metal core dumps for RISC-V Andrew Burgess
2020-12-02 17:39 ` [PATCH 1/8] gdb/riscv: use a single regset supply function for riscv fbsd & linux Andrew Burgess
2021-01-18 14:15 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file Andrew Burgess
2020-12-02 18:21 ` Luis Machado via Gdb-patches
2020-12-02 22:58 ` Jim Wilson
2020-12-03 12:16 ` Luis Machado via Gdb-patches
[not found] ` <20201214115512.GI2945@embecosm.com>
2021-01-11 10:19 ` Andrew Burgess
2021-01-11 13:03 ` Luis Machado via Gdb-patches
2020-12-07 12:48 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 3/8] gdb: write target description into " Andrew Burgess
2020-12-03 20:36 ` Tom Tromey
2020-12-07 14:38 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 4/8] bfd/riscv: prepare to handle bare metal core dump creation Andrew Burgess
2020-12-02 23:24 ` Jim Wilson
2020-12-07 14:39 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 5/8] gdb/riscv: introduce bare metal core dump support Andrew Burgess
2020-12-02 18:12 ` Luis Machado via Gdb-patches
2020-12-07 15:17 ` Andrew Burgess
2020-12-07 15:58 ` Luis Machado via Gdb-patches
2020-12-07 16:58 ` Andrew Burgess
2020-12-07 17:24 ` Luis Machado via Gdb-patches [this message]
2020-12-07 18:11 ` Andrew Burgess
2020-12-07 19:00 ` Luis Machado via Gdb-patches
2020-12-07 19:23 ` Andrew Burgess
2020-12-07 19:39 ` Luis Machado via Gdb-patches
2020-12-07 19:51 ` Paul Mathieu via Gdb-patches
2020-12-13 10:13 ` Fredrik Hederstierna via Gdb-patches
2020-12-02 17:39 ` [PATCH 6/8] bfd/binutils: add support for RISC-V CSRs in core files Andrew Burgess
2020-12-02 23:50 ` Jim Wilson
2020-12-07 15:19 ` Andrew Burgess
2020-12-14 13:37 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 7/8] gdb/riscv: make riscv target description names global Andrew Burgess
2020-12-02 17:39 ` [PATCH 8/8] gdb/riscv: write CSRs into baremetal core dumps Andrew Burgess
2020-12-02 23:59 ` [PATCH 0/8] Bare-metal core dumps for RISC-V Jim Wilson
2020-12-07 12:10 ` Andrew Burgess
2020-12-07 19:57 ` Jim Wilson
2020-12-03 20:40 ` Tom Tromey
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=615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org \
--to=gdb-patches@sourceware.org \
--cc=andrew.burgess@embecosm.com \
--cc=binutils@sourceware.org \
--cc=fredrik.hederstierna@verisure.com \
--cc=luis.machado@linaro.org \
--cc=paulmathieu@google.com \
/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