From: Marc Khouzam <marc.khouzam@ericsson.com>
To: "'Pedro Alves'" <pedro@codesourcery.com>,
"'gdb@sourceware.org'" <gdb@sourceware.org>
Subject: RE: Breakpoints and multi-process using the same binary
Date: Mon, 11 Apr 2011 18:05:00 -0000 [thread overview]
Message-ID: <F7CE05678329534C957159168FA70DEC5738DD2CD2@EUSAACMS0703.eamcs.ericsson.se> (raw)
In-Reply-To: <201104111816.30042.pedro@codesourcery.com>
> -----Original Message-----
> From: Pedro Alves [mailto:pedro@codesourcery.com]
> Sent: Monday, April 11, 2011 1:16 PM
> To: gdb@sourceware.org
> Cc: Marc Khouzam
> Subject: Re: Breakpoints and multi-process using the same binary
>
> On Monday 11 April 2011 15:52:45, Marc Khouzam wrote:
> > Hi,
> >
> > the next release of Eclipse CDT will make use of GDB's great
> > multi-process (multi-exec) support. Nice work!
> >
> > Quick question about breakpoints in that case (with non-stop).
> > I'm trying to set a breakpoint in a process that has one
> > thread stopped. The problem is that there is another
> > process fully running, which uses the same binary
> > (parent/child of a fork()).
> >
> > From what I can see, I cannot set such a breakpoint without
> > interrupting a thread for each and every process sharing the
> > binary.
> >
> > I just wanted to confirm that this was the right behavior
> > for GDB.
>
> Yeah, it's a current limitation. I've looked at this a
> bit after Tom reporting some other multi-process breakage, and
> it didn't look like a quick fix. You may not need that
> against linux gdbserver since it allows reading/writing
> memory even when threads are running, while native linux gdb
> doesn't.
Thanks for mentioning that, I was not aware of it, but did
confirm it just now. I was able to set a breakpoint while
the inferior was completely running using gdbserver, but
only with GDB 7.3 (even 7.2.1 didn't support it).
For native gdb (or pre-7.3), I'll have to interrupt a thread
for every process before dealing with breakpoints.
(I could be more efficient and look for processes that have
the same executable, but I won't break my head over that
small optimization).
> We're likely to get to fix all of this for
> proper ptsets/itsets support (which we'll be starting
> on real soon).
Looking forward to it.
Thanks for the quick answer.
Marc
prev parent reply other threads:[~2011-04-11 18:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 14:53 Marc Khouzam
2011-04-11 17:16 ` Pedro Alves
2011-04-11 18:05 ` Marc Khouzam [this message]
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=F7CE05678329534C957159168FA70DEC5738DD2CD2@EUSAACMS0703.eamcs.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=gdb@sourceware.org \
--cc=pedro@codesourcery.com \
/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