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

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 10 March 2010 22:22:51, Pierre Muller wrote:

> > Sorry, I already explained long ago that TARGET_OBJECT_OSDATA
> > is being misused here.  
>   OK, I start to remember now,
> you said that TARGET_OBJECT_DATA should use xml syntax for 
> all data transmission, what that it?

Basically repeating from
<http://sourceware.org/ml/gdb-patches/2009-07/msg00011.html>:

TARGET_OBJECT_OSDATA is meant be used through the
get_osdata interface, which assumes the target returns
xml encoded tabular form data.  See gdb/osdata.c, and 
the "info os" command (use and implementation).  You
can try "info os processes" against linux native or
gdbserver to see it in action.  The basic idea of this
object, is to be able to fetch tables of operating system
related data, like the list of running processes, or the
list of running threads, which are the present uses.

> > Why the resistence to change that?
> It's not resistance, its just that I have no xml knowledge,
> and I still don't really understand why 
> xml should be required for all TARGET_OBJECT_DATA.

See above.

> > There's another bit you haven't addressed yet:
> > 
> > > +     if (len == 8)
> > > +       {
> > > +         uint64_t tlb = th->thread_local_base;
> > > +         memcpy ((void *)readbuf, (void *) &tlb, len);
> > > +         return len;
> > > +       }
> > > +          else if (len == 4)
> > 
> > As I explained before, for partial xfers you should not
> > design the protocol relying on `len' being exactly 4 or 8.
> > Also, this is just transfering a number, why make that
> > target-endian dependant (see memcpy above) ?
> 
>   My code does assume that there is a unique call that
> will fetch either 4 bytes (for windows 32 bit inferior)
> or 8 bytes for (windows 64 bit inferior) in a unique call,
> which avoids the static struct used in the linux counter part...
> (I could have added a check that offset is zero).
> 
>   Anyhow, if you insist on using xml, you will need to 
> help me on how to handle and extract the relevant data from
> the generated xml.

I never insisted you used xml...  I do insist however,
that everything that goes through TARGET_OBJECT_OSDATA
respects the get_osdata interface, and that, is
tabular/xml based transfer of data.

Basically repeating from:
<http://sourceware.org/ml/gdb-patches/2009-07/msg00015.html>:

So, if you want to use the qxfer interface, please
add a new target object.  One note: I think target object's spirit is
to transfer  the whole data block, which is what would make
sense to me when requesting a TLB _object_.   The reason that
makes me consider transfering the whole blob instead of an address
and then relying on plain memory reads issued from GDB,
is that on other targets that may want to reuse the
interface, the TLB-like object may not be mapped or
accessible on the address space accessible with plain memory
reads.  This is exactly the rationale behind objects like
TARGET_OBJECT_AUXV, TARGET_OBJECT_WCOOKIE or
TARGET_OBJECT_SIGNAL_INFO: each of these objects can
be seen as a blob of data in its own address space.

If just transfering the address of the data is the way
to go, as you're doing presently, then I'm not certain
the xfer_partial interface is a good fit for this --- for
example, a simple packet like we use to fetch the tls data
pointer seems like a better fit.  For example, a new
target_get_thread_local_block target method, and a
new "qGetTLBAddr:XXX" packet: see the "qGetTLSAddr:" packet
for inspiration.

I don't have a strong preference which of the directions
above should be followed, but, mind you, but, as I said
before, TARGET_OBJECT_OSDATA isn't the right interface for
this.

-- 
Pedro Alves