Re: Remote query for structure layout
Simon Marchi via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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