Re: [RFC] if (INNER_THAN (read_sp(), step_sp - 16))

[Michael Snyder <msnyder at cygnus dot com>]

"Peter.Schauer" wrote:
> 
> Hellooooooo.
> 
> This ugly hack is coming back to haunt me every other year, and if I'd
> know about a cleaner way to solve this, I'd already have done it long ago.
> 
> You already asked me about this `gem' in August 1999 and I tried to explain
> the issue back then (see appended message below).

> As of CVS GDB from May 27 2001 this hack is still needed for
> Solaris x86 and Linux x86 (at least for a debian 2.2r2 release, for which
> I have just run the signals.exp test with and without the hack).

Ah -- I see.  Yep, I get that failure too.  Good, now at least I know
how to manifest the problem that the code is trying to fix.  

> Kevin Buettner also tried to come up with a better solution to no avail
> (see second message below).
> 
> I think we have two options here:
> 
> - Back out the change unconditionally as Andrew suggested and live with
>   the signals.exp regressions this will cause.
> 
> - Try to refine the test, so that the `serious bugs in debugging native
>   Linux x86' are not triggered.
>   Which problems are you encountering due to the hack ?

Basically, there are any number of ways in which the current SP
may be off by 16 or more from the SP at the beginning of the step.
The most likely problem is that we hit a breakpoint in the middle
of a line (eg. a step_resume breakpoint), but this test tells us
that we are not at a breakpoint.  If that happens, we may report
a random SIGTRAP, or worse, we may attempt to resume the target
without first decrementhing the PC.

To demonstrate this problem, build the "gdb.base/break.exp" test case
and load it into GDB.  Set a breakpoint at line 79, the call to
printf(factorial(atoi("6))).  Now set a breakpoint on the last 
instruction of this line, and attempt a "next".  On my red hat 7.0
linux system, this causes the inferior to SEGV, because it resumes
after the breakpoint without decrementing the PC (because it failed
to recognize that it was at a breakpoint).

We will have to decide whether this is a worse problem than
the problem you were trying to fix.

Michael