This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
RE: problem switching between threads
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: RE: problem switching between threads
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Fri, 19 May 2000 10:26:12 -0400 (EDT)
- cc: Andrew Cagney <ac131313 at cygnus dot com>, jtc at redback dot com, gdb at sourceware dot cygnus dot com
On Thu, 18 May 2000, Daniel Berlin wrote:
> > "J.T. Conklin" wrote:
> > >
> > > One of my back burner tasks is to adapt our vxWorks/WDB target to use
> > > GDB's own thread infrastructure instead of maintaining its own thread
> > > list, etc. Earlier today I added code to add each thread to GDB's
> > > thread list while I was building my the one used by the WDB target.
> > > This did not work as well as I expected.
> > >
> > > The problem is that switch_to_thread() does not resume the currently
> > > running thread nor suspend the thread being switched to. Things get
> > > confused as a result. The old task sits around doing nothing, while
> > > GDB thinks the new task is suspended when it may be executing.
> > >
> > > Has anyone else encountered this, or is GDB's thread support only used
> > > for targets where all threads stop when one is under debug?
> >
> > J.T.
> >
> > I believe your analysis is correct.
> >
> > Andrew
> Not only is it correct, but rather than try to get GDB to properly suspend
> the right thread, and resume it at the right time, I convinced a kernel
> engineer at Be to add a flag to stop all child threads/threads in a team
> when a thread entered the debugger.
> It's that harrowing to try to solve the problem.
> As i've said before, most of the work getting GDB to work on BeOS was
> working around GDB itself.
> :)
> --Dan
>
I am busy with making thread support over gdb protocol, I am done with
remote.c and I am half way through reference stub implmentation.
As part of this work I looked through GDB itself. Here are my findings:
1. Some targets (e.g. remote and extended remote) falsely claim that
they can lock the scheduler, so GDB is trying to do things
it is generally unable to do, e.g. do control thread switch.
2. Moreover, the only control thread model GBD core is REALLY able to work
with is NO thread control: all continue and step operations could be
done only in the context of the whole process not a specified thread.
3. The only data thread model supportable by current GDB core is shared
data and instructions memories between threads (e.g. no data cache
flush happen when thread switch occurs).
Thanks,
Aleksey