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
next prev 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