This is the mail archive of the
mailing list for the GDB project.
counter intuitive remote target behavior in GDB 7.7
- From: David Taylor <dtaylor at emc dot com>
- To: gdb at sourceware dot org
- Date: Thu, 01 May 2014 16:53:42 -0400
- Subject: counter intuitive remote target behavior in GDB 7.7
- Authentication-results: sourceware.org; auth=none
I'm seeing some counter intuitive remote target behavior in GDB 7.7.
We're writing a new GDB stub to replace our old GDB stub and there are
some behaviors by GDB that seem counter intuitive when talking to the
I start GDB with an ELF file, I set debug packet (so I can see the
behavior I'm describing here), target-async, non-stop, turn off paging
(set height 0) and then I do a target remote with appropriate arguments.
NOTE: remote, not extended-remote. We might support extended-remote in
the future, but not yet.
GDB sends a qSupported packet; we respond saying what we support; GDB is
happy with the response.
GDB sends Hg0 (select any thread), we say OK.
GDB sends QNonStop:1, we say OK, GDB sends qfThreadInfo, we respond with
a list of 50+ thread ids (the example in front of me has 65 thread ids).
qAttached -- we respond '1' (yes, we support qAttached, no you didn't
create the process / thread that you are attached to).
vCont? -- we respond with vCont;c;C;s;S;t
Everything is fine so far; *BUT*, notably, GDB has NOT asked what thread
it got when it did the Hg0 -- no qC packet has been seen.
GDB now does a vCont;t:1
To which I want to say WTF?
It *IS* okay for the user to explicitly and intentionally stop thread 1
or *MOST* threads on the system. If you explicitly stop a thread and
you screw yourself, well it's your fault -- be more careful next time.
It is *NOT* okay for GDB to 'randomly' decide to stop thread 1 (or any
other thread for that matter).
When Hg0 was received the stub selected a good thread for GDB to stop
(in fact, the thread is likely already stopped).
GDB now does qsThreadInfo to get the rest of the thread list. Then a
qTStatus (T0;tnotrun:0 for the example in front of me), qTfV (empty --
no thread state variables yet in the new stub).
Then '?' and a sequence of vStopped packets to get the list of currently
*FINALLY* GDB issues a qC to which, in this instance we respond with
QC41 -- thread 65.
Then it's qOffsets, qSymbol, another qTStatus, and a qTfP.
Next it does a Hg1 (the first stopped thread -- stopped only because GDB
decided to stop it!); reads the thread's registers, and reads memory at
the current pc location.
Then 4 qTStatus messages within nothing in between.
Then it goes through each of the remaining stopped threads, reads the
registers and the memory at the stopped pc location.
To summarize --
It asked the stub to pick a current thread; which the stub did.
It eventually asked the stub which thread it picked -- never using the
result; but not until after first stopping a thread of its own choosing.
It then changed the current thread several times -- throwing away the
thread selection that was done initially.
And it did a total of 6 qTStatus messages -- 4 of them without any other
messages in between.