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

[Pedro Alves <pedro@codesourcery.com>]

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