public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: Daniel Jacobowitz <drow@mvista.com>,
	Chris Zankel <zankel@tensilica.com>, <gdb@sources.redhat.com>
Subject: Re: RFC: Available registers as a target property
Date: Tue, 10 May 2005 00:03:00 -0000	[thread overview]
Message-ID: <BEA57277.A192%schlie@comcast.net> (raw)

> The daemon would already have to be updated to understand any new
> protocol extensions, so we're talking about modifying that agent in
> any case.  Given that, can you explain what advantage we would gain
> by having GDB pass configuration information to the daemon, instead of
> having the daemon parse some text file at startup and then communicate
> the configuration information to GDB?

Possibly because it's GDB which needs to know about both the symbolic and
semantics associated with registers and their interpretation, a target
interface only needs to know which and in what order GDB expects to have
their values communicated in, not what they mean, or how logically relate
to the program being debugged.

I.e. a target interface only needs to know how to retrieve/update register
values for a particular physical or simulated target, usually established
by convention, and possibly optionally identify a target more specifically
to GDB by returning a configuration status word typically defined by
configurable processors, or by simply literally specifying to GDB which
configuration to presume when invoked, just as is essentially done today,
as one can't expect to debug a PPC if GDB is configured to presume an x86
target for example.


             reply	other threads:[~2005-05-10  0:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-10  0:03 Paul Schlie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-05-17 23:08 Paul Schlie
2005-05-10 11:12 Paul Schlie
2005-05-09 22:39 Paul Schlie
2005-05-06 16:20 Daniel Jacobowitz
2005-05-07 10:25 ` Eli Zaretskii
2005-05-07 16:19   ` Daniel Jacobowitz
2005-05-07 19:37     ` Eli Zaretskii
2005-05-09 15:37       ` Daniel Jacobowitz
2005-05-09 20:58         ` Eli Zaretskii
2005-05-07 16:04 ` Mark Kettenis
2005-05-09 16:20   ` Daniel Jacobowitz
2005-05-09 15:57 ` Paul Brook
2005-05-09 16:32   ` Daniel Jacobowitz
2005-05-09 21:33 ` Chris Zankel
2005-05-09 23:07   ` Daniel Jacobowitz
2005-05-10  0:23     ` Chris Zankel
2005-05-10 21:08       ` Daniel Jacobowitz
2005-05-12 23:35         ` Chris Zankel
2005-05-17 14:03           ` Daniel Jacobowitz
2005-05-10  0:54 ` Ramana Radhakrishnan
2005-05-10 21:14   ` Daniel Jacobowitz
2005-05-17 19:32 ` Daniel Jacobowitz
2005-05-18  9:29   ` Richard Earnshaw
2005-05-19  1:00     ` Daniel Jacobowitz
2005-05-20 14:54       ` Richard Earnshaw

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=BEA57277.A192%schlie@comcast.net \
    --to=schlie@comcast.net \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=zankel@tensilica.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).