This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using XML in GDB?


Daniel Jacobowitz wrote:
There isn't a definitive conclusion because it's evolved substantially
once I began (re-) implementing it.  This is what I had two weeks ago:

http://sourceware.org/ml/gdb/2005-05/msg00171.html

But it doesn't look entirely like that any more.

Registers can be generically described without hard-coded GDB
knowledge.  Most other features can't, except for their presence or
absence.  But the point of suggesting XML is to keep this extensible
should someone have a bright idea :-)

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.


More generally we have been looking at ways to pass back information about the target to replace the GDB scripts we currently use that just trust that the target is as they describe - there is no check that the user hasn't connected to the wrong type.

You may remember that my proposal concerning a plugin interface provided means for the target plugin to run GDB commands. This was one way I planned to solve this problem.

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;
- memory map (not that GDB seems to do much with this at present);
- non-core control/information registers;
- other features.


'Other features' includes simulator specific trace features, silicon specific performance measurement devices, low level jtag commands etc. These things are controlled through custom GDB commands that may or may not be available on any given target.

In general, there is a selection of GDB 'set' commands which are of interest to targets and for which an interface might be nice.

None of this directly addresses the question of XML, but it does represent the sort of thing (some) users are looking to do, and therefore what 'extensibility' might entail. Of course, I'm still not sure exactly what you envisage as the limits of the interface.

Speaking of XML, are you aware of the SPIRIT SOC definition standard (http://www.spiritconsortium.com) which contains some things that the debugger might be interested in (and much in which it is not). I've no idea how compatible they are, but it might be nice if GDB could pull relevant information out of one of these.

Thanks

Andrew Stubbs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]