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

[Andrew Burgess]

* Luis Machado <luis.machado@linaro.org> [2020-12-07 16:00:06 -0300]:

> On 12/7/20 3:11 PM, Andrew Burgess wrote:
> > * 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.
> 
> Sorry, I think you're reading too deeply into what I said.
> 
> All I've suggested is to let the interested parties know you're doing this
> work, get their feedback on the strategy for dumping data for bare metal
> targets (I've cc-ed two of them, so they can chime in), see if that works
> for them with little to no extra work, and document it in a formal way (say,
> in gdb.texinfo).
> 
> That's it. I'm not talking about code, patch or implementation. I'm talking
> about a bare metal core file draft design that everyone is happy with, and
> based on which folks can go and implement what they want without having to
> dig into GDB's code for that.
> 
> You have the RISC-V implementation (it looks good to me FWIW), that's fine.
> But what is it implementing? It is not documented anywhere, is it? It is
> just following whatever Linux is doing, which is already badly
> documented.

Oh, OK!  That's much smaller in scope then.

Jim already asked about getting this documented in a different reply,
my plan is to document the RISC-V parts of this into the RISC-V elf
abi document (assuming the maintainers of that document accept such a
patch).

I'll re-review Fredrik's v4 patch and see if there's anything we can
share there, though from my first look through we're basically doing
the same thing already as that's the only obvious approach to take
(assuming the goal is ELF + NOTES).

I'll also reread your comments on numbering of the tdesc note and see
if there's a better number I can/should propose.

Thanks,
Andrew




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