From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: Re: Single stepping and threads
Date: Wed, 29 Nov 2006 05:58:00 -0000 [thread overview]
Message-ID: <20061129055915.GM9968@adacore.com> (raw)
In-Reply-To: <20061129052942.GA16029@nevyn.them.org>
> The default is "off". Should it be "step" instead?
I am not sure. On the one hand, I personally think that the current
behavior makes it harder to debug the program. I've been fustrated
a few times in the past when my next/step command got interrupted
and I found myself in another thread -> I kept using breakpoints
to do what I needed to do.
On the other hand, this has been the default behavior for so long
that it's something you expect... I don't know how much this will
impact the users. At AdaCore, I don't remember receiving any report
of that sort from our users, and tasking in Ada is something that's
commonly used.
The other argument against is that the debugger is supposed to be
transparent to the execution. This is not 100% true, but I think
we are very very close to it. Except maybe with certain thread
layers? Not sure, this is not my area of expertise, to say the
least. But for sure changing the setting to either "on" or "step"
will cause the debugger to affect the scheduling of the inferior.
So, to summarize, I'm somewhat in favor. I'll poll my team-mates
and see if they have any interesting ideas to share on the subject.
> One reason I've procrastinated bringing this up is that set
> scheduler-locking off, the current default, has a lot more nasty
> corner cases that I've meant to look into; if step becomes the default,
> I suspect more of those will linger unfixed. But users won't encounter
> them as often, which is much like fixing them :-)
I agree with that. If we decide to make that change, and that hides
issues as a result, then these particular issues become less important,
and you can spend the time working on other things that you like.
> A related issue is the tendency of "step" to let other threads run even
> in "set scheduler-locking step". For instance:
[...]
> - "step" acts like "next" when stepping over a function without debug
> info. Should we honor "set scheduler-locking step" when doing
> this?
I would say yes. A step should be a few instructions, while stepping
over a call is potentially a much larger number of instructions.
As a result, stepping over without letting the other threads go would
more likely cause a lock.
--
Joel
PS: My understanding is that not all systems support the running
of an individual thread instead of the entire program. Is that
right? Or do all systems support this feature?
next prev parent reply other threads:[~2006-11-29 5:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 5:29 Daniel Jacobowitz
2006-11-29 5:58 ` Joel Brobecker [this message]
2006-11-29 13:25 ` Daniel Jacobowitz
2006-11-29 16:38 ` Joel Brobecker
2006-11-30 13:54 ` Daniel Jacobowitz
2006-11-30 23:36 ` Michael Snyder
2006-11-30 23:54 ` Joel Brobecker
2006-12-01 1:02 ` Daniel Jacobowitz
2006-12-01 22:43 ` Michael Snyder
2006-12-02 16:27 ` Rob Quill
2006-12-02 16:33 ` Daniel Jacobowitz
2006-12-02 16:36 ` Joel Brobecker
2006-12-04 19:50 ` Michael Snyder
2006-11-30 8:44 ` Robert Dewar
2006-11-30 23:32 ` Michael Snyder
2006-11-30 23:26 ` Michael Snyder
2006-11-30 23:31 ` Joel Brobecker
2006-11-29 12:41 ` Mark Kettenis
2006-11-29 13:36 ` Daniel Jacobowitz
2006-11-30 23:38 ` Michael Snyder
2006-11-30 23:22 ` 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=20061129055915.GM9968@adacore.com \
--to=brobecker@adacore.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