Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* 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