This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PING] [RFC-v3] Add windows Thread Information Block
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Daniel Jacobowitz <dan at codesourcery dot com>
- Cc: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>, gdb-patches at sourceware dot org
- Date: Thu, 11 Mar 2010 00:11:15 +0000
- Subject: Re: [PING] [RFC-v3] Add windows Thread Information Block
- References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <000c01cac0a0$3935fbe0$aba1f3a0$@muller@ics-cnrs.unistra.fr> <20100310233035.GA2056@caradoc.them.org>
On Wednesday 10 March 2010 23:30:40, Daniel Jacobowitz wrote:
> On Wed, Mar 10, 2010 at 11:22:51PM +0100, Pierre Muller wrote:
> > OK, I start to remember now,
> > you said that TARGET_OBJECT_DATA should use xml syntax for
> > all data transmission, what that it?
>
> My two cents... the issue isn't that you aren't using XML, but that
> you're using TARGET_OBJECT_OSDATA. That's for information about the
> operating system, like the list of all running processes, not about
> the current process.
>
> Pedro, this raises an interesting question. Suppose Pierre added a
> new qXfer object. How would he indicate to a remote target which
> process's object was requested? This may be something already
> handled, but I don't know the answer.
The "general thread" is reused for target objects. There's
no way in the protocol to select a process as context, other than
selecting a thread of it. Example, TARGET_OBJECT_SIGNAL_INFO
(for $_siginfo) transfers from the remote protocol
current|general thread. I think we'd do the same for this? A
non-thread specific xfer example: TARGET_OBJECT_AUXV transfers
from the process of the currently selected thread.
Some packets specify the thread/process explicitly. For example,
the `qGetTLBAddr' packet alternative would do like
`qGetTLSAddr' does: `qGetTLBAddr:TID...' if multiprocess
is off, or `qGetTLBAddr:pPID.TID...' if multiprocess is
on.
--
Pedro Alves