* PATCH: resume + threads + software stepping == boom
@ 2001-06-08 12:34 Daniel Jacobowitz
2001-06-08 14:10 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2001-06-08 12:34 UTC (permalink / raw)
To: gdb-patches
resume () in infrun.c has this block:
if (SOFTWARE_SINGLE_STEP_P () && step)
{
/* Do it the hard way, w/temp breakpoints */
SOFTWARE_SINGLE_STEP (sig, 1 /*insert-breakpoints */ );
/* ...and don't ask hardware to do it. */
step = 0;
Then, further down, if (use_thread_step_needed && thread_step_needed)
and there's already a breakpoint at the PC, is this:
if (!step)
{
warning ("Internal error, changing continue to step.");
That blows up, because step will always be zero here if
SOFTWARE_SINGLE_STEP_P (). Is this patch OK? It seems to work in my tests
here.
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
From ac131313@cygnus.com Fri Jun 08 12:48:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: brobecker@act-europe.fr, gdb-patches@sources.redhat.com
Subject: Re: patch to gdb on Tru64 5.1
Date: Fri, 08 Jun 2001 12:48:00 -0000
Message-id: <3B212C20.6090005@cygnus.com>
References: <3AFC67C4.9000102@cygnus.com> <200105130240.f4D2eiU07396@rtl.cygnus.com>
X-SW-Source: 2001-06/msg00172.html
Content-length: 592
> On 11-May-2001, Andrew Cagney wrote:
>
>
>> o is it possible to compile in both tables
>> so that the correct table can be selected
>> at run time. In theory allowing GDB to
>> handle both 4.x and 5.x core files.
>
>
> There's only one table. In the transition from 4.x to 5.x, EF_* #defines
> in system header files were renamed to CF_*, but their values didn't
> change. Therefore, a single table allows GDB to handle both 4.x and 5.x
> core files.
>
> Maybe a comment to that effect would be enough to prevent future
> confusion?
Yes, ok, that explains it. Thanks,
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-08 12:34 PATCH: resume + threads + software stepping == boom Daniel Jacobowitz
@ 2001-06-08 14:10 ` Daniel Jacobowitz
2001-06-08 16:19 ` Michael Snyder
2001-06-09 13:34 ` Andrew Cagney
2 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2001-06-08 14:10 UTC (permalink / raw)
To: gdb-patches
On Fri, Jun 08, 2001 at 12:34:32PM -0700, Daniel Jacobowitz wrote:
> resume () in infrun.c has this block:
>
> if (SOFTWARE_SINGLE_STEP_P () && step)
> {
> /* Do it the hard way, w/temp breakpoints */
> SOFTWARE_SINGLE_STEP (sig, 1 /*insert-breakpoints */ );
> /* ...and don't ask hardware to do it. */
> step = 0;
>
> Then, further down, if (use_thread_step_needed && thread_step_needed)
> and there's already a breakpoint at the PC, is this:
>
> if (!step)
> {
> warning ("Internal error, changing continue to step.");
>
> That blows up, because step will always be zero here if
> SOFTWARE_SINGLE_STEP_P (). Is this patch OK? It seems to work in my tests
> here.
Oops, forgot a changelog entry for this one.
2001-06-08 Daniel Jacobowitz <drow@mvista.com>
* infrun.c (resume): Add ostep variable. Test ostep
instead of step.
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-08 12:34 PATCH: resume + threads + software stepping == boom Daniel Jacobowitz
2001-06-08 14:10 ` Daniel Jacobowitz
@ 2001-06-08 16:19 ` Michael Snyder
2001-06-08 16:20 ` Michael Snyder
2001-06-09 13:34 ` Andrew Cagney
2 siblings, 1 reply; 11+ messages in thread
From: Michael Snyder @ 2001-06-08 16:19 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
>
> resume () in infrun.c has this block:
>
> if (SOFTWARE_SINGLE_STEP_P () && step)
> {
> /* Do it the hard way, w/temp breakpoints */
> SOFTWARE_SINGLE_STEP (sig, 1 /*insert-breakpoints */ );
> /* ...and don't ask hardware to do it. */
> step = 0;
>
> Then, further down, if (use_thread_step_needed && thread_step_needed)
> and there's already a breakpoint at the PC, is this:
>
> if (!step)
> {
> warning ("Internal error, changing continue to step.");
>
> That blows up, because step will always be zero here if
> SOFTWARE_SINGLE_STEP_P (). Is this patch OK? It seems to work in my tests
> here.
I like the problem analysis, but not the implementation of the solution.
If we are going to always set step to zero for SOFTWARE_SINGLE_STEP_P,
then it does not make sense to set it to one again, even if the code
will never be reached (in theory). I would rather see it made explicit
that this code should never be reached if SOFTWARE_SINGLE_STEP_P is true.
Something like this:
< if (!step)
---
> if (!(step && SOFTWARE_SINGLE_STEP_P()))
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-08 16:19 ` Michael Snyder
@ 2001-06-08 16:20 ` Michael Snyder
2001-06-08 16:43 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Michael Snyder @ 2001-06-08 16:20 UTC (permalink / raw)
To: Daniel Jacobowitz, gdb-patches
Michael Snyder wrote:
>
> Daniel Jacobowitz wrote:
> >
> > resume () in infrun.c has this block:
> >
> > if (SOFTWARE_SINGLE_STEP_P () && step)
> > {
> > /* Do it the hard way, w/temp breakpoints */
> > SOFTWARE_SINGLE_STEP (sig, 1 /*insert-breakpoints */ );
> > /* ...and don't ask hardware to do it. */
> > step = 0;
> >
> > Then, further down, if (use_thread_step_needed && thread_step_needed)
> > and there's already a breakpoint at the PC, is this:
> >
> > if (!step)
> > {
> > warning ("Internal error, changing continue to step.");
> >
> > That blows up, because step will always be zero here if
> > SOFTWARE_SINGLE_STEP_P (). Is this patch OK? It seems to work in my tests
> > here.
>
> I like the problem analysis, but not the implementation of the solution.
> If we are going to always set step to zero for SOFTWARE_SINGLE_STEP_P,
> then it does not make sense to set it to one again, even if the code
> will never be reached (in theory). I would rather see it made explicit
> that this code should never be reached if SOFTWARE_SINGLE_STEP_P is true.
> Something like this:
>
> < if (!step)
> ---
> > if (!(step && SOFTWARE_SINGLE_STEP_P()))
Err, my logic is wrong, but you get the idea... maybe I meant
if (!step && !SOFTWARE_SINGLE_STEP_P())
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-08 16:20 ` Michael Snyder
@ 2001-06-08 16:43 ` Daniel Jacobowitz
[not found] ` <3B225994.9060502@cygnus.com>
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2001-06-08 16:43 UTC (permalink / raw)
To: Michael Snyder; +Cc: gdb-patches
On Fri, Jun 08, 2001 at 04:20:30PM -0700, Michael Snyder wrote:
> Michael Snyder wrote:
> > I like the problem analysis, but not the implementation of the solution.
> > If we are going to always set step to zero for SOFTWARE_SINGLE_STEP_P,
> > then it does not make sense to set it to one again, even if the code
> > will never be reached (in theory). I would rather see it made explicit
> > that this code should never be reached if SOFTWARE_SINGLE_STEP_P is true.
> > Something like this:
> >
> > < if (!step)
> > ---
> > > if (!(step && SOFTWARE_SINGLE_STEP_P()))
>
> Err, my logic is wrong, but you get the idea... maybe I meant
> if (!step && !SOFTWARE_SINGLE_STEP_P())
>
Does SOFTWARE_SINGLE_STEP_P () contradict the error we are detecting
here? From reading the surrounding code, I'm not entirely sure what
the case is; is it: the current thread has stopped at a breakpoint,
and we do not want to let other threads continue, so we require that we
be single stepping so that one thread does not run independently?
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-08 12:34 PATCH: resume + threads + software stepping == boom Daniel Jacobowitz
2001-06-08 14:10 ` Daniel Jacobowitz
2001-06-08 16:19 ` Michael Snyder
@ 2001-06-09 13:34 ` Andrew Cagney
2001-06-09 15:44 ` Daniel Jacobowitz
2 siblings, 1 reply; 11+ messages in thread
From: Andrew Cagney @ 2001-06-09 13:34 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel,
Just FYI, I don't see an assignment/diclaimer on record. Is this the
case? At present your patches are just sneeking in under the bar.
enjoy,
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-09 13:34 ` Andrew Cagney
@ 2001-06-09 15:44 ` Daniel Jacobowitz
2001-06-11 17:53 ` Jim Blandy
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2001-06-09 15:44 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
On Sat, Jun 09, 2001 at 01:17:52PM -0400, Andrew Cagney wrote:
> Daniel,
>
> Just FYI, I don't see an assignment/diclaimer on record. Is this the
> case? At present your patches are just sneeking in under the bar.
Right, there isn't one yet. I'm going to take care of that next week -
these are just the independent portions of the MIPS patches, and when I
hit the actual port... Even despite the fact that David Miller and Ralf
Baechle originally wrote it I've added enough that it certainly won't
fit under the bar.
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
[not found] ` <3B225994.9060502@cygnus.com>
@ 2001-06-09 16:05 ` Daniel Jacobowitz
2001-06-10 21:40 ` Michael Snyder
2001-06-13 15:21 ` Michael Snyder
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2001-06-09 16:05 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Michael Snyder, gdb-patches
On Sat, Jun 09, 2001 at 01:15:00PM -0400, Andrew Cagney wrote:
> Could I suggest:
>
> > On Fri, Jun 08, 2001 at 04:20:30PM -0700, Michael Snyder wrote:
> >
> >> Michael Snyder wrote:
> >
> >> > I like the problem analysis, but not the implementation of the solution.
> >> > If we are going to always set step to zero for SOFTWARE_SINGLE_STEP_P,
> >> > then it does not make sense to set it to one again, even if the code
> >> > will never be reached (in theory). I would rather see it made explicit
> >> > that this code should never be reached if SOFTWARE_SINGLE_STEP_P is true.
> >> > Something like this:
> >> >
> >> > < if (!step)
> >> > ---
> >
> >> > > if (!(step && SOFTWARE_SINGLE_STEP_P()))
> >
> >>
> >> Err, my logic is wrong, but you get the idea... maybe I meant
> >> if (!step && !SOFTWARE_SINGLE_STEP_P())
>
>
> Dumping the warning("internal error: ...") and replacing the entire
> block of code with something like:
>
> gdb_assert (step || SOFTWARE_SINGLE_STEP_P ())
>
> (I know my logic is wrong). That way the problem of ``never reached (in
> theory)'' is eliminated.
My concern is that this is a weaker assertion than was intended. How
about this - it changes the meaning of the assertion slightly since
it's not conditional on should_resume, but I think it'll be correct
none the less:
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.35
diff -u -r1.35 infrun.c
--- infrun.c 2001/06/02 00:36:20 1.35
+++ infrun.c 2001/06/09 23:05:32
@@ -850,6 +850,11 @@
if (breakpoint_here_p (read_pc ()) == permanent_breakpoint_here)
SKIP_PERMANENT_BREAKPOINT ();
+ /* If we stopped on a breakpoint and it was not deleted, we want to continue
+ only this thread, so we should be stepping. */
+ gdb_assert (step || !use_thread_step || !thread_step_needed ||
+ !breakpoint_here_p (read_pc ()));
+
if (SOFTWARE_SINGLE_STEP_P () && step)
{
/* Do it the hard way, w/temp breakpoints */
@@ -927,14 +932,7 @@
}
else
{
- if (!step)
- {
- warning ("Internal error, changing continue to step.");
- remove_breakpoints ();
- breakpoints_inserted = 0;
- trap_expected = 1;
- step = 1;
- }
+ /* Breakpoint not deleted, so step only this thread. */
resume_ptid = inferior_ptid;
}
}
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-09 16:05 ` Daniel Jacobowitz
@ 2001-06-10 21:40 ` Michael Snyder
2001-06-13 15:21 ` Michael Snyder
1 sibling, 0 replies; 11+ messages in thread
From: Michael Snyder @ 2001-06-10 21:40 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, Michael Snyder, gdb-patches
Daniel Jacobowitz wrote:
[extensive snipping]
> + /* If we stopped on a breakpoint and it was not deleted, we want to continue
> + only this thread, so we should be stepping. */
I agree with the premise -- whenever we resume at a breakpoint,
we should do a single-thread-step before inserting bps, so that
other threads do not have a chance to run (and possibly go past
other breakpoints) while breakpoints are not inserted.
How do others feel about that premise? I think we had
reached that consensus at some earlier time, but it has not
been implemented (almost, but not quite).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-09 15:44 ` Daniel Jacobowitz
@ 2001-06-11 17:53 ` Jim Blandy
0 siblings, 0 replies; 11+ messages in thread
From: Jim Blandy @ 2001-06-11 17:53 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb-patches
Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:
> On Sat, Jun 09, 2001 at 01:17:52PM -0400, Andrew Cagney wrote:
> > Daniel,
> >
> > Just FYI, I don't see an assignment/diclaimer on record. Is this the
> > case? At present your patches are just sneeking in under the bar.
>
> Right, there isn't one yet. I'm going to take care of that next week -
> these are just the independent portions of the MIPS patches, and when I
> hit the actual port... Even despite the fact that David Miller and Ralf
> Baechle originally wrote it I've added enough that it certainly won't
> fit under the bar.
I've e-mailed him the form.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: resume + threads + software stepping == boom
2001-06-09 16:05 ` Daniel Jacobowitz
2001-06-10 21:40 ` Michael Snyder
@ 2001-06-13 15:21 ` Michael Snyder
1 sibling, 0 replies; 11+ messages in thread
From: Michael Snyder @ 2001-06-13 15:21 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb-patches
Daniel Jacobowitz wrote:
>
> On Sat, Jun 09, 2001 at 01:15:00PM -0400, Andrew Cagney wrote:
> > Could I suggest:
> >
> > > On Fri, Jun 08, 2001 at 04:20:30PM -0700, Michael Snyder wrote:
> > >
> > >> Michael Snyder wrote:
> > >
> > >> > I like the problem analysis, but not the implementation of the solution.
> > >> > If we are going to always set step to zero for SOFTWARE_SINGLE_STEP_P,
> > >> > then it does not make sense to set it to one again, even if the code
> > >> > will never be reached (in theory). I would rather see it made explicit
> > >> > that this code should never be reached if SOFTWARE_SINGLE_STEP_P is true.
> > >> > Something like this:
> > >> >
> > >> > < if (!step)
> > >> > ---
> > >
> > >> > > if (!(step && SOFTWARE_SINGLE_STEP_P()))
> > >
> > >>
> > >> Err, my logic is wrong, but you get the idea... maybe I meant
> > >> if (!step && !SOFTWARE_SINGLE_STEP_P())
> >
> >
> > Dumping the warning("internal error: ...") and replacing the entire
> > block of code with something like:
> >
> > gdb_assert (step || SOFTWARE_SINGLE_STEP_P ())
> >
> > (I know my logic is wrong). That way the problem of ``never reached (in
> > theory)'' is eliminated.
>
> My concern is that this is a weaker assertion than was intended. How
> about this - it changes the meaning of the assertion slightly since
> it's not conditional on should_resume, but I think it'll be correct
> none the less:
Daniel, just to let you know, I'm still thinking about this.
As you may or may not have noticed, I'm in the process of submitting
a bunch of bug fixes in infrun.c thread handling code. I won't
forget about this one. ;-)
Michael
>
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.35
> diff -u -r1.35 infrun.c
> --- infrun.c 2001/06/02 00:36:20 1.35
> +++ infrun.c 2001/06/09 23:05:32
> @@ -850,6 +850,11 @@
> if (breakpoint_here_p (read_pc ()) == permanent_breakpoint_here)
> SKIP_PERMANENT_BREAKPOINT ();
>
> + /* If we stopped on a breakpoint and it was not deleted, we want to continue
> + only this thread, so we should be stepping. */
> + gdb_assert (step || !use_thread_step || !thread_step_needed ||
> + !breakpoint_here_p (read_pc ()));
> +
> if (SOFTWARE_SINGLE_STEP_P () && step)
> {
> /* Do it the hard way, w/temp breakpoints */
> @@ -927,14 +932,7 @@
> }
> else
> {
> - if (!step)
> - {
> - warning ("Internal error, changing continue to step.");
> - remove_breakpoints ();
> - breakpoints_inserted = 0;
> - trap_expected = 1;
> - step = 1;
> - }
> + /* Breakpoint not deleted, so step only this thread. */
> resume_ptid = inferior_ptid;
> }
> }
>
> --
> Daniel Jacobowitz Debian GNU/Linux Developer
> Monta Vista Software Debian Security Team
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-06-13 15:21 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-08 12:34 PATCH: resume + threads + software stepping == boom Daniel Jacobowitz
2001-06-08 14:10 ` Daniel Jacobowitz
2001-06-08 16:19 ` Michael Snyder
2001-06-08 16:20 ` Michael Snyder
2001-06-08 16:43 ` Daniel Jacobowitz
[not found] ` <3B225994.9060502@cygnus.com>
2001-06-09 16:05 ` Daniel Jacobowitz
2001-06-10 21:40 ` Michael Snyder
2001-06-13 15:21 ` Michael Snyder
2001-06-09 13:34 ` Andrew Cagney
2001-06-09 15:44 ` Daniel Jacobowitz
2001-06-11 17:53 ` Jim Blandy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox