[PATCH] Fix problem with scope.exp test, skipping past init0 call

[PATCH] Fix problem with scope.exp test, skipping past init0 call

[Fred Fish]

I noticed the following failures while running the gdb testsuite and
decided to investigate:

  Running /src/latest/trunk/src/gdb/gdb/testsuite/gdb.base/scope.exp ...
  FAIL: gdb.base/scope.exp: next over init0() in main
  FAIL: gdb.base/scope.exp: print filelocal_bss
  FAIL: gdb.base/scope.exp: print 'scope0.c'::filelocal_bss in test_at_main
  FAIL: gdb.base/scope.exp: print 'scope1.c'::filelocal_bss

The problem was triggered by the fact that the breakpoint on main was
being set at the opening brace and then the first next only took us to
the init0 call.  This might be a bug in it's own right, but scope.exp
is supposed to handle this as a side effect of an attempt to skip
__main:

    # skip past init.  There may be a call to __main at the start of
    # main, so the first next may only get us to the init0 call.
    if [gdb_test "next" "$decimal.*foo \\(\\);" "next over init0() in main"  "$decimal.*init0 \\(\\);" "next"] {
      gdb_suppress_tests ;
    }

However, it appears that you can only using the additional "QUESTION
RESPONSE" args to gdb_test for true questions (that don't end in a
newline) and not for the way attempted here.  The following patch
fixes the problem.

2006-02-12  Fred Fish  <fnf@specifix.com>

	* gdb.base/scope.exp (test_at_main): Use gdb_test_multiple
	to handle cases where it takes two "next" commands to skip
	past the init call.

Index: scope.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/scope.exp,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 scope.exp
*** scope.exp	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- scope.exp	12 Feb 2006 20:04:37 -0000
*************** proc test_at_main {} {
*** 63,70 ****
  
      # skip past init.  There may be a call to __main at the start of
      # main, so the first next may only get us to the init0 call.
!     if [gdb_test "next" "$decimal.*foo \\(\\);" "next over init0() in main"  "$decimal.*init0 \\(\\);" "next"] { 
!       gdb_suppress_tests ; 
      }
  
  
--- 63,80 ----
  
      # skip past init.  There may be a call to __main at the start of
      # main, so the first next may only get us to the init0 call.
!     gdb_test_multiple "next" "next over init0() in main" {
! 	-re "$decimal.*foo \\(\\).*$gdb_prompt $" {
! 	    pass "next over init0() in main"
! 	}
! 	-re "$decimal.*init0 \\(\\).*$gdb_prompt $" {
! 	    send_gdb "next\n"
! 	    exp_continue
! 	}
! 	-re ".*$gdb_prompt $" {
! 	    fail "next over init0() in main"
! 	    gdb_suppress_tests
! 	}
      }
  
  

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Jim Blandy]

On 2/12/06, Fred Fish <fnf@specifix.com> wrote:
> 2006-02-12  Fred Fish  <fnf@specifix.com>
>
>         * gdb.base/scope.exp (test_at_main): Use gdb_test_multiple
>         to handle cases where it takes two "next" commands to skip
>         past the init call.

Looks good to me.

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Daniel Jacobowitz]

While Jim's already approved the patch, and it's fine, some other
notes...

On Sun, Feb 12, 2006 at 03:10:01PM -0500, Fred Fish wrote:
> I noticed the following failures while running the gdb testsuite and
> decided to investigate:
> 
>   Running /src/latest/trunk/src/gdb/gdb/testsuite/gdb.base/scope.exp ...
>   FAIL: gdb.base/scope.exp: next over init0() in main
>   FAIL: gdb.base/scope.exp: print filelocal_bss
>   FAIL: gdb.base/scope.exp: print 'scope0.c'::filelocal_bss in test_at_main
>   FAIL: gdb.base/scope.exp: print 'scope1.c'::filelocal_bss

What platform and compiler version is this?  It doesn't fail for me.

> The problem was triggered by the fact that the breakpoint on main was
> being set at the opening brace and then the first next only took us to
> the init0 call.  This might be a bug in it's own right, but scope.exp
> is supposed to handle this as a side effect of an attempt to skip
> __main:
> 
>     # skip past init.  There may be a call to __main at the start of
>     # main, so the first next may only get us to the init0 call.
>     if [gdb_test "next" "$decimal.*foo \\(\\);" "next over init0() in main"  "$decimal.*init0 \\(\\);" "next"] {
>       gdb_suppress_tests ;
>     }

Well, that's supposed to skip a call to __main(), which GCC generates
on very few platforms... stopping at the opening brace is definitely
a bug in its own right, in the debug info or in the prologue skipper.


-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Fred Fish]

On Monday 13 February 2006 10:39, Daniel Jacobowitz wrote:
> What platform and compiler version is this?  It doesn't fail for me.

Fedora Core 4, using the latest development gcc while running the]
gdb testsuite.

> Well, that's supposed to skip a call to __main(), which GCC generates
> on very few platforms... stopping at the opening brace is definitely
> a bug in its own right, in the debug info or in the prologue skipper.

The problem is that gcc now generates prologues that the prologue skipper
isn't prepared to handle.

The latest gcc generates prologues like:

main:
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ecx
        call    foo

While older gcc's generate a prologue that
gdb understands, like:

main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
        call    foo

So when compiling with the latest gcc, gdb will set a function
breakpoint at the same address as main.

I was just reviewing the mailing lists to see if anyone else has
reported this, or is working on it, before doing any work on
i386_analyze_frame_setup().

-Fred

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Daniel Jacobowitz]

On Mon, Feb 13, 2006 at 10:47:30AM -0500, Fred Fish wrote:
> > Well, that's supposed to skip a call to __main(), which GCC generates
> > on very few platforms... stopping at the opening brace is definitely
> > a bug in its own right, in the debug info or in the prologue skipper.
> 
> The problem is that gcc now generates prologues that the prologue skipper
> isn't prepared to handle.

Hmm, many arches other than i386 are more trusting of line information
than i386 is - but we've historically had some problems with bad
versions of gcc there so it's understandable.

> The latest gcc generates prologues like:
> 
> main:
>         leal    4(%esp), %ecx
>         andl    $-16, %esp
>         pushl   -4(%ecx)
>         pushl   %ebp
>         movl    %esp, %ebp
>         pushl   %ecx
>         call    foo

Ahh - your GCC has unaligned stack support for main.  Not surprising
that GDB can't handle this; it's clever, and fresh off the presses.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Mark Kettenis]

> From: Fred Fish <fnf@specifix.com>
> Date: Mon, 13 Feb 2006 10:47:30 -0500
> 
> On Monday 13 February 2006 10:39, Daniel Jacobowitz wrote:
> > What platform and compiler version is this?  It doesn't fail for me.
> 
> Fedora Core 4, using the latest development gcc while running the]
> gdb testsuite.

Hmm, if you didn't commit the fix yet, can you please hold off doing
that for a bit?  From your explanation below, it turns out that this
might have caught a genuine genuine GDB bug.  By "fixing" this we're
likely not to notice that.  And if this would have been a GCC bug that
would have been fixed in the official release, there would have been
no reason to have added a workaround either.

> > Well, that's supposed to skip a call to __main(), which GCC generates
> > on very few platforms... stopping at the opening brace is definitely
> > a bug in its own right, in the debug info or in the prologue skipper.
> 
> The problem is that gcc now generates prologues that the prologue skipper
> isn't prepared to handle.
> 
> The latest gcc generates prologues like:
> 
> main:
>         leal    4(%esp), %ecx
>         andl    $-16, %esp
>         pushl   -4(%ecx)
>         pushl   %ebp
>         movl    %esp, %ebp
>         pushl   %ecx
>         call    foo

Hmm, what's happening here?  Looks like the first three instructions
are aligning the stack on a 16-byte boundary.  Why is GCC doing that?

Mark

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Daniel Jacobowitz]

On Mon, Feb 13, 2006 at 05:04:49PM +0100, Mark Kettenis wrote:
> > > Well, that's supposed to skip a call to __main(), which GCC generates
> > > on very few platforms... stopping at the opening brace is definitely
> > > a bug in its own right, in the debug info or in the prologue skipper.
> > 
> > The problem is that gcc now generates prologues that the prologue skipper
> > isn't prepared to handle.
> > 
> > The latest gcc generates prologues like:
> > 
> > main:
> >         leal    4(%esp), %ecx
> >         andl    $-16, %esp
> >         pushl   -4(%ecx)
> >         pushl   %ebp
> >         movl    %esp, %ebp
> >         pushl   %ecx
> >         call    foo
> 
> Hmm, what's happening here?  Looks like the first three instructions
> are aligning the stack on a 16-byte boundary.  Why is GCC doing that?

In case the system runtime doesn't (which some older glibc crt files
didn't, or maybe it's kernel dependent, or something like that that's
hard to handle when configuring GCC).  You need the 16-byte alignment
for SSE2, I think?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Fred Fish]

On Monday 13 February 2006 11:04, Mark Kettenis wrote:
> Hmm, if you didn't commit the fix yet, can you please hold off doing
> that for a bit?  From your explanation below, it turns out that this
> might have caught a genuine genuine GDB bug.  By "fixing" this we're
> likely not to notice that.

I believe it also causing lots of other testsuite failures as well.
The scope.exp fix was special in that the original test was supposed
to handle needing two successive "next" commands to get past init0,
and that wasn't working.

-Fred

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Mark Kettenis]

> From: Fred Fish <fnf@specifix.com>
> Date: Mon, 13 Feb 2006 11:18:49 -0500
> 
> On Monday 13 February 2006 11:04, Mark Kettenis wrote:
> > Hmm, if you didn't commit the fix yet, can you please hold off doing
> > that for a bit?  From your explanation below, it turns out that this
> > might have caught a genuine genuine GDB bug.  By "fixing" this we're
> > likely not to notice that.
> 
> I believe it also causing lots of other testsuite failures as well.
> The scope.exp fix was special in that the original test was supposed
> to handle needing two successive "next" commands to get past init0,
> and that wasn't working.

Ok.  Can you file a bug report for the prologue analyzer bug?  I'll
take a look at fixing it.

Mark

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Jim Blandy]

Actually, having seen other's responses here, I'm inclined to say that
the proper fix is to simply drop the code in scope.exp for getting
from the opening brace to the first line.  Setting a breakpoint on
main simply shouldn't leave you on the opening brace, and that test
suite logic has always been papering over a bug.

If prologues contain calls to __main, then the prologue analyzers
should skip them.

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Jim Blandy]

On 2/13/06, Jim Blandy <jimb@red-bean.com> wrote:
> Actually, having seen other's responses here, I'm inclined to say that
> the proper fix is to simply drop the code in scope.exp for getting
> from the opening brace to the first line.  Setting a breakpoint on
> main simply shouldn't leave you on the opening brace, and that test
> suite logic has always been papering over a bug.
>
> If prologues contain calls to __main, then the prologue analyzers
> should skip them.

My penance; scope.exp still has no failures on x86_64-unknown-linux-gnu.

gdb/testsuite/ChangeLog:
2006-02-13  Jim Blandy  <jimb@redhat.com>

	* gdb.base/scope.exp (test_at_main): Remove logic to handle the
	case where it takes two "next" commands to skip past the init
	call.

Index: gdb/testsuite/gdb.base/scope.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/scope.exp,v
retrieving revision 1.10
diff -c -p -r1.10 scope.exp
*** gdb/testsuite/gdb.base/scope.exp	13 Feb 2006 10:41:26 -0000	1.10
--- gdb/testsuite/gdb.base/scope.exp	13 Feb 2006 17:52:39 -0000
*************** proc test_at_main {} {
*** 61,82 ****
      global subdir
      global hp_cc_compiler

!     # skip past init.  There may be a call to __main at the start of
!     # main, so the first next may only get us to the init0 call.
!     gdb_test_multiple "next" "next over init0() in main" {
! 	-re "$decimal.*foo \\(\\).*$gdb_prompt $" {
! 	    pass "next over init0() in main"
! 	}
! 	-re "$decimal.*init0 \\(\\).*$gdb_prompt $" {
! 	    send_gdb "next\n"
! 	    exp_continue
! 	}
! 	-re ".*$gdb_prompt $" {
! 	    fail "next over init0() in main"
! 	    gdb_suppress_tests
! 	}
!     }
!

      # Print scope0.c::filelocal, which is 1

--- 61,72 ----
      global subdir
      global hp_cc_compiler

!     # skip past init0.
!     # This used to do an extra "next" if the first one didn't get us
!     # over the call to init0, to handle calls to __main in the
!     # prologue, etc.  But if a breakpoint at main doesn't leave us on
!     # the first line of real code in the function, that's a GDB bug.
!     gdb_test "next" "$decimal.*foo \\(\\);" "next over init0() in main"

      # Print scope0.c::filelocal, which is 1

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Jim Blandy]

This also should go in gdb.arch/i386-prologue.{c,exp}.

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Mark Kettenis]

> Date: Mon, 13 Feb 2006 09:57:43 -0800
> From: Jim Blandy <jimb@red-bean.com>
> 
> This also should go in gdb.arch/i386-prologue.{c,exp}.

Indeed.  I already have a testcase for it, which I will commit
together with the fix for the i386 prologue analyzer.

Mark

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Fred Fish]

On Monday 13 February 2006 11:48, Mark Kettenis wrote:
> Ok.  Can you file a bug report for the prologue analyzer bug?  I'll
> take a look at fixing it.

Done.  breakpoints/2080

-Fred

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Michael Snyder]

Jim Blandy wrote:
> Actually, having seen other's responses here, I'm inclined to say that
> the proper fix is to simply drop the code in scope.exp for getting
> from the opening brace to the first line.  Setting a breakpoint on
> main simply shouldn't leave you on the opening brace, and that test
> suite logic has always been papering over a bug.
> 
> If prologues contain calls to __main, then the prologue analyzers
> should skip them.

Are you sure?  If skipping __main involves overhead,
do you want to incur that overhead every time we want
to skip a prologue?

Re: [PATCH] Fix problem with scope.exp test, skipping past init0 call

[Jim Blandy]

On 3/1/06, Michael Snyder <msnyder@redhat.com> wrote:
> Jim Blandy wrote:
> > Actually, having seen other's responses here, I'm inclined to say that
> > the proper fix is to simply drop the code in scope.exp for getting
> > from the opening brace to the first line.  Setting a breakpoint on
> > main simply shouldn't leave you on the opening brace, and that test
> > suite logic has always been papering over a bug.
> >
> > If prologues contain calls to __main, then the prologue analyzers
> > should skip them.
>
> Are you sure?  If skipping __main involves overhead,
> do you want to incur that overhead every time we want
> to skip a prologue?

Do you mean overhead in the analysis of the prologue to find its end,
or overhead in allowing the program to continue to the end of a
prologue that contains a call to __main?

If the first, I don't think it's a big deal.  If we don't see a jsr,
we won't incur any overhead.

If the second, the skip_prologue gdbarch method gets used in the
following situations:

- When we're stepping into a function.  Here, we use the step-resume
breakpoint to step when we get to the end of the prologue, so there's
no overhead that I see to skipping over __main.  We're not
single-stepping over the call.

- When we're setting a breakpoint at a function start.  Obviously, no
special run-time overhead here; you can set the breakpoint anywhere
you like.

- When we're trying to decide if a given address is in a prologue. 
Again, I don't see any impact.

I think this is a correctness issue anyway, not a performance issue. 
If a prologue contains a call to __main, it's our job to make sure
that works efficiently; we shouldn't change the behavior of
skip_prologue.