Re: Is the current gdb 5.1 broken for Linuxthreads?

[Eric Paire <paire at ri dot silicomp dot fr>]

> > I already started a thread to explain that that stopping all threads in
> > a synchronous way was an illusion: Think of a 2-way processor on which
> > 2 threads are running on each processor: If one thread stops, the time
> > required by one processor to handle the trap, discover that others
> > threads must be stopped, makwe the interprocessor request, ... allows
> > the other thread to run thousands of instructions on the second
> > processor before being stopped. The result is that you think all threads
> > have stopped at the same time, while it's false, even if you have the best
> > interface you can think of.
> 
> Just an aside, everyone will agree with your point that synchronized 
> thread stop model is an illusion.  However, that doesn't make the 
> model/illusion wrong.  Most other systems still make a synchronised halt 
> interface available since it is simple and fast - the complexity of 
> having to suspend all related threads being constrained to the kernel.
> 
>From the user point of view, it seems simple and fast. From the kernel
point of view, this is somewhat difficult to achieve (I already had to deal
with when I worked on OSF/MACH3.0), particularly on multi-processors
(on uniprocessors, all threads but the current one are not in running
state, while on MP, some of them may be in running state on other
processors). IMHO, although I admit that this is not very easy, we can
nevertheless stop all threads individually with SIGSTOP, so that I do
not see why we should add complexity in the kernel to simplify something
we can already do in the user space (and certainly, Linus doesn't for now).

There is another difficulty on Linux which seems much more important than
these ones. There is no support for MT core dumps. As Linus has always
refused to add such functionality in the kernel (which is somewhat similar
with your simple interface to stop all threads), a solution should be though
of in the user space.

-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web  : http://www.ri.silicomp.com/~paire  | Groupe SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com         | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71               | F-38610 Gieres
Fax  : +33 (0) 476 51 05 32               | FRANCE