This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Using XML in GDB?
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