Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support

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

* Luis Machado <luis.machado@linaro.org> [2020-12-07 14:24:33 -0300]:

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

Sure.

What I don't understand is you talk about creating "a format that
works for multiple architectures".

Current Linux/FreeBSD core files are a container (often ELF) with
NOTES containing additional information.

By format are you suggesting we come up with something non-ELF?  I
doubt this is the case, but if so, why would we want to do this?

Or are you suggesting some kind of coordination for note
names/numbers?  But I don't see how this is different to what we have
right now.

I'm tight on time right now, but I skimmed the threads you linked, I
looked at Fredrik's v4 patch[1] from Oct-25.  This patch had some of
the boiler-plate code lifted into a common file, which I could
integrate into my series, but otherwise the patches are pretty
similar.

You hadn't followed up to Fredrik's v4 patch[1], but based on your
comments to the v2 patch[2] I'm guessing you're still not happy with
v4 (please do correct me if this guess is wrong).

In your comments to Fredrik's v2 patch[2] you say:

  We should really discuss what the generic core file format for
  bare-metal targets will look like before having a possible patch to
  implement it. At least that's my take on it.

To which there's no follow up.  Is there a mail I've missed where you
sketch out your ideas for what this generic format might look like?

How about I propose something here to get the ball rolling, and you
(or others) can suggest improvements, or ask for clarifying questions:

 - A container file format, lets say ELF,
 - Loadable sections corresponding to the loaded memory contents,
 - A NOTES section containing auxiliary information, e.g.
   + Threads (thread per core?)
   + Registers for each thread

Unsurprisingly this lines up with what I've proposed, and if I'm
reading the patch correctly, with what Fredrik is also proposing.

Thanks,
Andrew

[1] https://sourceware.org/pipermail/gdb-patches/2020-October/172845.html
[2] https://sourceware.org/pipermail/gdb-patches/2020-October/172721.html