Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew STUBBS <andrew.stubbs@st.com>
To: gdb@sourceware.org
Subject: Re: Using XML in GDB?
Date: Thu, 26 Jan 2006 17:44:00 -0000	[thread overview]
Message-ID: <43D9076B.6080008@st.com> (raw)
In-Reply-To: <20060126163832.GA7113@nevyn.them.org>

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


  parent reply	other threads:[~2006-01-26 17:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-26  7:01 Daniel Jacobowitz
2006-01-26 12:45 ` Andrew STUBBS
2006-01-26 13:41   ` Daniel Jacobowitz
2006-01-26 16:24     ` Andrew STUBBS
2006-01-26 16:41       ` Daniel Jacobowitz
2006-01-26 17:34         ` Paul Koning
2006-01-26 17:44         ` Andrew STUBBS [this message]
2006-01-26 18:55           ` Daniel Jacobowitz
2006-01-26 21:05         ` Mark Kettenis
2006-01-26 21:26           ` Daniel Jacobowitz
2006-01-26 21:57             ` Mark Kettenis
2006-01-26 22:02               ` Daniel Jacobowitz
2006-01-26 22:32                 ` Bob Rossi
2006-01-26 20:39 ` Mark Kettenis
2006-01-26 20:43   ` Bob Rossi
2006-01-26 21:41     ` Mark Kettenis
2006-01-26 20:52   ` Daniel Jacobowitz
2006-01-26 21:12     ` Bob Rossi
2006-01-27  0:47 ` Bob Rossi
2006-01-27 18:04 ` Eli Zaretskii
2006-01-27 18:41   ` Daniel Jacobowitz
2006-01-27 18:57     ` Eli Zaretskii
2006-01-27 19:06       ` Paul Koning
2006-01-28  6:33         ` Daniel Jacobowitz
2006-01-28 13:54           ` Jim Blandy
2006-01-29  4:09             ` Eli Zaretskii
2006-01-29  4:27             ` Paul Koning
2006-01-28  5:24       ` Daniel Jacobowitz
2006-01-29  4:33 Paul Schlie
2006-01-29  6:18 ` Jim Blandy
2006-01-29 23:21   ` Daniel Jacobowitz
2006-01-29 23:24   ` Paul Schlie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D9076B.6080008@st.com \
    --to=andrew.stubbs@st.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox