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

[Luis Machado via Gdb-patches <gdb-patches@sourceware.org>]

On 12/7/20 4:23 PM, Andrew Burgess wrote:
> * 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.
> 

Indeed! It was never my goal to create more work for you.

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

Great. Apologies, I haven't been following the other bits too closely. I 
just replied to the ones I had immediate feedback on.

> 
> 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 think it is pretty safe to assume ELF + NOTES at this point.

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

That's probably a matter of personal taste. I've been frustrated before, 
trying to find the most logical new ID for a new NT_* constant and 
failing to parse the data.