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: problem switching between threads




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



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