Using XML in GDB?

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Thu, Jan 26, 2006 at 03:06:27PM +0000, Andrew STUBBS wrote:
>> That sounds good. We have been considering doing something with memory 
>> mapped registers (devices, exception/interrupt reason codes, etc.), and 
>> this might be the answer.
> 
> Would you expose them as registers, or as memory mapped I/O, from the
> stub?  If the latter, what sort of information would you want GDB to
> have about them, and how would you present them to the user or
> frontend?

Well, right now we have a script that sets up a lot of convenience 
variables (part of the reason for 'keep-variable') which contain the 
address of the register. This works, but is more than a little clunky, 
what with the dereferencing syntax.

If they could look like regular registers, but in another reggroup, that 
would be good.

>> Specifically, the data we need/want GDB to know about the target are as 
>> follows:
>>  - architecture variant (i.e. what registers and instructions are valid);
>>  - endian;
> 
> While I'm not covering these at the moment, I do plan to.  Right now
> I'm focusing on...
> 
>>  - non-core control/information registers;
> 
> ... registers otherwise unknown to GDB.  Completely target-specific
> features work too.

Good, as long as they are in the road map.

You have skipped memory maps.  Is there no plan to make an automatic 
'mem' command? I would prefer that the memory maps were honoured by a 
little more of GDB - attempts to access bad addresses can crash the 
target, but that's a separate project.

> I've vaguely heard of SPIRIT, but never any details.  Does it contain a
> useful amount of information that GDB might care about?

It lists all the IP blocks on an SoC, but more importantly the location, 
format (down to bit level in some cases) and content of all the memory 
mapped registers in the device. It also describes the memory regions in 
the various memory interface devices.

Even if it isn't of direct interest to the debugger, it may be of 
interest to the user and worth presenting.

This is why I suggest that you don't go out of your way to be 
incompatible. I'm not sure what it takes to be compatible, but since 
it's all XML, it might be enough to just not clash with any of its tags, 
or conversely use the same names where they happen to be the same format.

> I'm not going to pursue this for now because of IP issues; the terms on
> the SPIRIT documents make me leery of using them for an open source
> program, at least without talking to a lawyer about it first.

Really? I would have thought they would be OK (the point of SPIRIT is 
that everybody uses it), but IANAL and anyway I haven't read the terms.

Thanks

Andrew Stubbs