Break in a thread but continue other threads

Break in a thread but continue other threads

[David Highley]

Is it possible to put a break in one thread but continue all the other
threads? Our developers keep lamenting to me the inadequacies of the gdb
debugger in debugging our run time configured multi-threaded
applications. In several cases I can answer read the manual but in
others I know the persons diligence and capabilities. While ddd is ok it
would not be considered a great interface by any standard. I peronally
am not complaining as I do not use any of the integrated development
environments but I get plenty of input from the developer community;
300+ on just one program.

Re: Break in a thread but continue other threads

[Daniel Jacobowitz]

On Fri, Feb 16, 2007 at 08:02:42AM -0800, David Highley wrote:
> Is it possible to put a break in one thread but continue all the other
> threads?

GDB only supports examining the program when it is fully (all threads)
stopped.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Break in a thread but continue other threads

[Nicholas Mc Guire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Is it possible to put a break in one thread but continue all the other
> threads? Our developers keep lamenting to me the inadequacies of the gdb
> debugger in debugging our run time configured multi-threaded
> applications. In several cases I can answer read the manual but in
> others I know the persons diligence and capabilities. While ddd is ok it
> would not be considered a great interface by any standard. I peronally
> am not complaining as I do not use any of the integrated development
> environments but I get plenty of input from the developer community;
> 300+ on just one program.
>

One posible solution for this problem would be to use tracepoints - we
have completed the first version of tracepoints for Linux (PPC,MIPS,X86)
and it is available via cvs at:

  cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs login
  password: anoncvs
  cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs co tracepoints

In the cvs you also can find a preliminary user manual - but this is still
work in progress.
Its also in ftp (cvs snapshot) at:

  ftp://dslab.lzu.edu.cn:/pub/gdb_tracepoints

the monolitic patches for the current version are in:

  ftp://dslab.lzu.edu.cn:/pub/gdb_tracepoints/tracepoint-release/tracepoint-0.2

basically you only need that one patch file unless you are interested in 
the internals and want to join in (which we off course don't mind).

Note though that there are some principle problems with ptrace based 
debugging (on Linux at least) as a thread that enteres via ptrace_stop
are delayed until the next tick, which causes relatively large delays -
this seems to be a Linux "bug" though which simply did not bother anybody
as long as breakpoints are interactive only.

hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFF1revnU7rXZKfY2oRAjeQAJ95uupGgnYxmGjyFKrinXxGSgcS9gCfUWyz
u4KDAzlunXtyxaINJAhgrsg=
=1v8L
-----END PGP SIGNATURE-----

Re: Break in a thread but continue other threads

[Eli Zaretskii]

> Date: Sat, 17 Feb 2007 09:07:09 +0100 (CET)
> From: Nicholas Mc Guire <der.herr@hofr.at>
> cc: gdb@sourceware.org
> 
> One posible solution for this problem would be to use tracepoints - we
> have completed the first version of tracepoints for Linux (PPC,MIPS,X86)
> and it is available via cvs at:
> 
>   cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs login
>   password: anoncvs
>   cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs co tracepoints

Any reasons why this wasn't submitted for inclusion in GDB?

Re: Break in a thread but continue other threads

[Nicholas Mc Guire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Date: Sat, 17 Feb 2007 09:07:09 +0100 (CET)
>> From: Nicholas Mc Guire <der.herr@hofr.at>
>> cc: gdb@sourceware.org
>>
>> One posible solution for this problem would be to use tracepoints - we
>> have completed the first version of tracepoints for Linux (PPC,MIPS,X86)
>> and it is available via cvs at:
>>
>>   cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs login
>>   password: anoncvs
>>   cvs -d :pserver:anoncvs@dslab.lzu.edu.cn:/home/cvs co tracepoints
>
> Any reasons why this wasn't submitted for inclusion in GDB?
>
It just was completed last week and is not ready yet for inclusion - it
simply did not get enough testing yet. Also we are still missing a few
commands (i.e. two of the tfind commands) and we have a few glitches
to cleanup first (fist tfind is ignored, breakpoints and tracepoints at
the same address fail, etc.).

Also one problem is that GDB requires that copyright is assigned to the 
GDB project (correct me if thats wrong) and Siemens AG witch sponsored the 
work is only willing to release it under GPL V2 but not give up copyright.

I have no problem with this going into GDB mainstream though once its
clean (and documented).

BTW I would like a small change to the tracepoint comand interface if
posible - I would need an extra parameter to tstart that would allow to
pass the number of traceevents that will occure so that one can allocate
memory on the target side before the trace experiment starts instead of
during runtime

hofrat

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFF1t/0nU7rXZKfY2oRAqq1AJ9DUnP20AEIJ43efudiDSBOUeN0mQCgk1/S
5SWuOg2IVrZ/xwU0gmOzBVc=
=StrV
-----END PGP SIGNATURE-----

Re: Break in a thread but continue other threads

[Michael Snyder]

On Fri, 2007-02-16 at 08:02 -0800, David Highley wrote:
> Is it possible to put a break in one thread but continue all the other
> threads?

No, gdb has a very simple model for thread debugging:
either all threads are running, or all are stopped.
* Except as noted below...


>  Our developers keep lamenting to me the inadequacies of the gdb
> debugger in debugging our run time configured multi-threaded
> applications. In several cases I can answer read the manual but in
> others I know the persons diligence and capabilities. While ddd is ok it
> would not be considered a great interface by any standard. I peronally
> am not complaining as I do not use any of the integrated development
> environments but I get plenty of input from the developer community;
> 300+ on just one program.

* Theoretically, you might set a thread-specific breakpoint
and attach to it the command "set scheduler-locking on".
If your host / target supports scheduler locking, this 
would prevent any other thread from running, whereupon
you could simply "continue".

However, use at your own risk... it's a great way to
create a deadlock.  I haven't tried this, usual disclaimers
apply...