Re: [PING] [RFC-v3] Add windows Thread Information Block

Pedro Alves
2010-03-11T00:11:25Z

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