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

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

Hi Pedro,

> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé?: Thursday, March 11, 2010 1:01 AM
> À?: gdb-patches@sourceware.org
> Cc?: Pierre Muller
> Objet?: Re: [PING] [RFC-v3] Add windows Thread Information Block
> 
> 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>:

  Sorry to bother you and bug you with all that.
I really completely forgot these last emails, I should have
reread them before sending this PING.

> 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.
OK, so let's use another scheme.
 
> > > 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.
 So I will try this out, but adding new target methods
is something I am afraid of not being capable...
  I will probably need so time to get that working...

  Pedro, 
  I would like to apologize here, because my first email
sounded like an attack on you, but it was just that I I
still had not understood your reasons for the opposition 
against another use of TARGET_OBJECT_OSDATA.
  I was thinking that the Thread Information Block was an
OS specific feature, and as such would clearly be eligible 
for the use of TARGET_OBJECT_OSDATA.
  Your answer that it should all be processed through the
get_osdata function has finally convinced me.
It should already have last year, but I must have been 
in a 'worse' mind and didn't understand your reasons then.


Thanks for all,

Pierre