Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nicholas Mc Guire <der.herr@hofr.at>
To: David Highley <dhighley@highley-recommended.com>
Cc: gdb@sourceware.org
Subject: Re: Break in a thread but continue other threads
Date: Sat, 17 Feb 2007 10:37:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.60.0702170849540.1566@rtl14.hofr.at> (raw)
In-Reply-To: <200702161602.l1GG2gpr014571@douglas.highley-recommended.com>

-----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-----


  parent reply	other threads:[~2007-02-17  8:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 16:06 David Highley
2007-02-16 17:19 ` Daniel Jacobowitz
2007-02-17 10:37 ` Nicholas Mc Guire [this message]
2007-02-17 13:16   ` Eli Zaretskii
2007-02-17 13:51     ` Nicholas Mc Guire
2007-02-21  1:10 ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.60.0702170849540.1566@rtl14.hofr.at \
    --to=der.herr@hofr.at \
    --cc=dhighley@highley-recommended.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox