This is the mail archive of the
mailing list for the GDB project.
Remote protocol: creation and destruction of threads
- From: Raphael Zulliger <zulliger at indel dot ch>
- To: gdb at sourceware dot org
- Date: Fri, 17 Dec 2010 13:43:27 +0100
- Subject: Remote protocol: creation and destruction of threads
How does GDB notice the creation (or destruction) of threads in the
inferior when debugging a remote target ('target (extended-)remote')?
I'm developing a GDB stub suitable for my company's self-made, single
process, multi threading, real-time, embedded OS. The OS supports
'non-stop' debugging out of the box. My stub is working quite well
already. Things like getting thread information, backtrace and frame
inspection, stepping, etc. mostly work. Therefore, GDB is already very
useful for debugging our OS.
Here's the version info of the GDB I'm using (self compiled):
GNU gdb (GDB) 7.2
This GDB was configured as "--host=i686-pc-linux-gnu
Among others, I have the following problem I need to solve:
Assume the following use case:
- GDB already connected to my stub (target extended-remote
localhost:xxxx, options: target-async 1, pagination off, non-stop on)
- GDB and my stub did all the initial data exchange stuff. Additionally,
GDB already asked for the list of threads
- GDB is now ready for 'user commands'
- some time goes by
- Suddenly, for whatever reason, the embedded OS creates a new thread...
- ...my stub notices the new thread (for this use case, assume the
thread is 'running')
What should my stub do now? What's the design of GDB for this case?
- Is it the idea that the stub will never inform GDB about thread
creation (or deletion)? Instead, GDB will refresh the list when required
(e.g. when the user issues 'info thread')? If this is the case, how can
we ensure that GUIs (like Eclipse) will notice the new thread and show
it in the list of threads?
- Should the stub issue a "%Stop" notification mentioning the new thread(s)?
- Other things that need to be done?
I created a small test application (Ubuntu/x86), that spontaneously
creates and destroys threads. To figure out what GDB is expected to
receive from my stub, I started that test application with 'gdbserver'
and started debugging the application with GDB (using the same options
as mentioned above plus 'debug remote 1'). My GDB version is:
GNU gdb (GDB) 7.1-ubuntu.....This GDB was configured as
What I noticed is that there happens absolutely no communication between
'gdbserver' and GDB. To be honest, I expected to see some kind of
notification... I now wonder whether GDB does not support such kind of
'notification' at all or whether I miss something (like setting an
option or the like).
I would appreciate any inputs/hints!
Thanks in advance,