This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: remote nits


>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> 1. I was mistaken there are 4 ways to represent thread:
Quality>    16-bit integer is used by 'qC' and 8-bit integer is used
Quality>    by 'TXX'.
Quality>
Quality> 2. Yes, there are at least 5 ways to solve this problem
Quality>    (invent something new or use one of 4 exiting ones). The
Quality>    question was which one is more appropriate ?

Perhaps the best thing to do is to deprecate the entire set of thread
commands and replace them with a consistantly designed and rigorously
specified set.  I believe that Michael Snyder expressed some interest
in doing some of this (in the context of thread list queries) in the
past.

Quality> I would go with following set of rules: (1)thread id is an
Quality> unsigned 64-bit integer represented on the wire in %x format
Quality> (leading zeros are omitted) in all transactions except 'qP',
Quality> 'qQ', 'qL' and 'qM' which use %08x representation;

Wouldn't that be %016x?

Quality> (2)requests 'Hc-xxxxxx' and 'Hg-xxxxx' should be interpreted
Quality> as 'all threads' regardless of the length and the pattern of
Quality> 'xxxxxx',

The notion of all-threads leads me to belive that perhaps we need some
way to specify both a context and a context id, even if GDB can't take
advantage of this at this time.  For example, possible contexts could
be 'system', 'process', or 'thread'.

The context id would most likely be irrelevant for the system context,
but would be the process id or or thread id for the process or thread
contexts.

One of our goals is a single GDB that can debug multiple processes the
same way (or even better) we can debug multiple threads today.  Since
those processes could have multiple threads, GDB will have to be able
to represent both the processes and the threads.  These contexts may
be a way to accomplish this.  I realize that a lot of work in GDB's
core is necessary, but if we're going to change the protocol at all,
we might as well future proof the investment.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]