Re: Remote query for structure layout

[Simon Marchi via Gdb <gdb@sourceware.org>]

On 2021-03-29 1:33 p.m., Thomas Weißschuh wrote:
> Hi!
> 
> On Mo, 2021-03-29T12:05-0400, Simon Marchi wrote:
>> On 2021-03-28 7:06 a.m., Thomas Weißschuh wrote:> Hi everybody,
>>> I would like to propose a new command for the remote protocol that can be used to
>>> query structure layouts.
>>> Essentially a `qSymbol` equivalent for the output of `ptype`.
>>>
>> I think that would make sense.  We already help the stub look up some
>> things in the debugged process using qSymbol, so it would be a bit silly
>> to say "now you're on your own to interpret it!".
> 
> Good to know, I'll take a shot at it.
> 
>> If we go there, we could also help the stub make the link between the
>> symbol and its type, so that you don't have to hardcode that symbol
>> "foo" is of type "foo_t".  For example, if you could also pass a symbol
>> name (like pxCurrentTCB) to qType, you wouldn't have to hardcode its
>> type name in the openocd source code, it's one less thing that can go
>> wrong.  Or it could be another packet that does symbol name to type
>> name, which you then pass to qType.
> 
> Would it not make more sense to report the type of a symbol as part of qSymbol?
> Gated behind a qSupported flag "qSymbol:type+" or so?

If it can easily be made in a backwards-compatible way (considering all
permutations of old gdb / new gdb, old stub / new stub), sure.

> What do you think about the dataformat of the qType response?
> Should it be a homegrown textformat or XML which would be much easier to
> extend.

The problem with XML is that it would need to be parsed on the target
side.  We try to keep things simple on the target, because that may be
on a constrained device, you don't want to have to include an
XML-parsing library.  XML the other way (from stub to GDB) is OK,
because it's easy to produce some basic XML using printf, and GDB can
link with an XML parsing library.

So I would lean towards a home-grown format, but it's more work to
ensure it is extensible if we want to include more information in the
replies in the future.

I don't know all the remote packets by heart, maybe there's one that
already uses a scheme that could be re-used here.  Otherwise, XML can
certainly be used to start prototyping.  With the appropriate
abstractions in place, it should be relatively easy to swap the
encoding for another one.

Simon