This is the mail archive of the
mailing list for the GDB project.
- From: David Taylor <dtaylor at emc dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 13 May 2014 12:06:56 -0400
- Subject: qXfer:threads questions
- Authentication-results: sourceware.org; auth=none
Some of these questions aren't specific to qXfer:threads:read, but are
inspired by it.
And for some of these, they can probably be answered by either a
detailed study of the GDB source code or by running experiments. But,
that merely tells you what GDB currently does. Not what the intent is.
I'd like to know the intent -- that is less likely to change from
release to release than the source code.
The qXfer:threads:read message is underspecified in the documentation.
And to the extent that it is specified, it surprises me.
We have a box with a fair number of threads / processes running in it.
It's a shared address space. All threads / processes run in the same
address space. The threads / processes running varies over time. If
you ask me right now what processes / threads are running on the box and
ask again in a minute, the answer will likely be different. The bulk
will be the same -- most get started when the box is brought up and
remain around until it is brought down. But, some threads / processes
come and go so there *WILL* be differences.
Reading the spec for qXfer:threads:read I get the impression that it is
meant to solve the problem of a system with a large but static list of
threads. I suspect that typically when the list is static, it is small
and when it is large, it is dynamic.
It takes both an offset and a length.
So, if I'm a gdb stub and I recieve the qXfer request, if I don't
currently have an XML string to satisfy the request, I create one. And
then I send a reply.
Now, about that reply:
. if at offset + length I am in the middle of an XML token, what should
. suppose that I back up to a boundary between <thread> ... </thread>
and end the reply there, is that allowed?
is it okay for the receiver (typically GDB) to consider that to be an
is it an error?
if it is not an error and is not an EOF (after all, I didn't send the
'trailer' yet), what offset will the next request use?
old offset + old length?
old offset + returned lenth?
. what if 'offset' is in the middle of an XML token?
To like to not have to pad the message out to 'offset' bytes with spaces
just to avoid errors / confusion.
Also, there's nothing in the documentation that requires that the reads
be in order nor that the next read start at any given boundary. Given
that the list is dynamic and consequently changes this is a problem.
. how do I know when to 'throw away' the old data and compute new data?
For data that is dynamic and computed on the fly, I much prefer the
qfThreadInfo / qsThreadInfo model.
The 'f' (first) starts at the beginning and gives information on one or
more 'items' (threads in this case) up to a maximum of PacketSize; the
's' (subsequent) ones start where the previous 'f' or 's' packet left
off and return information on one or more 'items' up to PacketSize. And
there is an EOF marker -- so the caller knows when to stop (though with
XML the 'tailer' is all you really need to know whether to stop).
With the 'f' / 's' model, I don't need to keep the XML structure around.
I only need to remember where in the process / thread table I was at the
end of the last message. Next 's' message I start from there; next 'f'
message I start over at the beginning. Simple and straightforward.
*IF* we were adding a new message, I'd probably suggest either:
That is give the 'annex' the value 'first' or 'next', require that
'offset' be omitted and that 'length' be greater than zero.
That is, keep the annext empty, give two 'offsets' with special
meanings, and again require that 'length' be greater than zero.
Or ... ?
Just throwing out possibilities.
Given the current existence of qXfer:threads:read I'd prefer a solution
that allows the stub to say 'I support the new qXfer threads message'
without any confusion about support for the old message -- so I would
tend to disfavor the first two for that reason. And I'd prefer to not
list two messages in qSupported to get one feature, so I would tend to
disfavor the third for that reason. So, I'd really prefer some 4th