[Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29850

            Bug ID: 29850
           Summary: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next
                    over longjmp(1)
           Product: gdb
           Version: 12.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In OBS, with a gdb 12.1 based package on SLE-12 SP3 powerpc64le, I ran into:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
^M
Breakpoint 3, main () at
/home/abuild/rpmbuild/BUILD/gdb-12.1/gdb/testsuite/gdb.base/longjmp.c:59^M
59        i = 1; /* miss_step_1 */^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29850

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
I noticed that in gdb.log (of the entire testsuite) the info probes command did
not show any libc probes, so I tried reproducing the fail on SLE-15 by ignoring
the relevant libc probe:
...
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 14204850e28..54286c7e705 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -3397,7 +3397,7 @@ create_longjmp_master_breakpoint (void)
            continue;

          /* Try a probe kind breakpoint on main objfile.  */
-         if (create_longjmp_master_breakpoint_probe (obj))
+         if (0 && create_longjmp_master_breakpoint_probe (obj))
            continue;

          /* Try longjmp_names kind breakpoints on main and separate_debug
...
and that worked.

However, I noticed when trying the same on x86_64:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
56            resumes++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
which is a nicer failure mode, given that we stop at the first line after the
longjmp target.

I tried to investigate the reason for this difference.

First of all, I noticed that for powerpc64le, no longjmp master breakpoint is
set due to:
...
static bool
create_longjmp_master_breakpoint_names (objfile *objfile)
{
  struct gdbarch *gdbarch = objfile->arch ();
  if (!gdbarch_get_longjmp_target_p (gdbarch))
    return false;
...
and after disabling the early-out, that is fixed, but the difference remains.

After analyzing debug infrun output, I realized the reason for the difference:
we get lucky with x86_64.  We have insns:
...
  4005c7:       e8 94 fe ff ff          call   400460 <_setjmp@plt>
  4005cc:       85 c0                   test   %eax,%eax
  4005ce:       75 1e                   jne    4005ee <main+0x3b>
  4005d0:       8b 05 8e 0a 20 00       mov    0x200a8e(%rip),%eax        #
601064 <longjmps>
  4005d6:       83 c0 01                add    $0x1,%eax
  4005d9:       89 05 85 0a 20 00       mov    %eax,0x200a85(%rip)        #
601064 <longjmps>
  4005df:       be 01 00 00 00          mov    $0x1,%esi
  4005e4:       bf 80 10 60 00          mov    $0x601080,%edi
  4005e9:       e8 82 fe ff ff          call   400470 <longjmp@plt>
  4005ee:       8b 05 74 0a 20 00       mov    0x200a74(%rip),%eax        #
601068 <resumes>
...
and when stepping into longjmp we set a breakpoint at the return pc:
...
  [infrun] insert_step_resume_breakpoint_at_sal_1: inserting step-resume
breakpoint at 0x4005ee
...
which also happens to be the pc that is the target of the branch at 0x4005ce,
ensuring that we'll hit this step-resume breakpoint when taking the longjmp
resume path.

With powerpc64le, we have insns:
...
    10000858:   09 fd ff 4b     bl      10000560
<00000019.plt_call._setjmp@@GLIBC_2.17>
    1000085c:   18 00 41 e8     ld      r2,24(r1)
    10000860:   78 1b 69 7c     mr      r9,r3
    10000864:   00 00 a9 2f     cmpdi   cr7,r9,0
    10000868:   3c 00 9e 40     bne     cr7,100008a4 <main+0x78>
    1000086c:   00 00 00 60     nop
    10000870:   44 81 22 39     addi    r9,r2,-32444
    10000874:   00 00 29 81     lwz     r9,0(r9)
    10000878:   b4 07 29 7d     extsw   r9,r9
    1000087c:   01 00 29 39     addi    r9,r9,1
    10000880:   b4 07 2a 7d     extsw   r10,r9
    10000884:   00 00 00 60     nop
    10000888:   44 81 22 39     addi    r9,r2,-32444
    1000088c:   00 00 49 91     stw     r10,0(r9)
    10000890:   01 00 80 38     li      r4,1
    10000894:   00 00 00 60     nop
    10000898:   50 81 62 38     addi    r3,r2,-32432
    1000089c:   e5 fc ff 4b     bl      10000580
<00000019.plt_call.longjmp@@GLIBC_2.17>
    100008a0:   18 00 41 e8     ld      r2,24(r1)
    100008a4:   00 00 00 60     nop
...
and when stepping into longjmp we set a breakpoint at the return pc:
...
  [infrun] insert_step_resume_breakpoint_at_sal_1: inserting step-resume
breakpoint at 0x100008a0
...
which is one insn before the branch target of the jump at 10000868, ensuring
that we'll not hit the step-resume breakpoint when taking the longjmp resume
path.

By inverting the branches:
...
diff --git a/gdb/testsuite/gdb.base/longjmp.c
b/gdb/testsuite/gdb.base/longjmp.c
index 4139e49e6f1..ce6990ca99a 100644
--- a/gdb/testsuite/gdb.base/longjmp.c
+++ b/gdb/testsuite/gdb.base/longjmp.c
@@ -46,14 +46,14 @@ main ()
   volatile int i = 0;

   /* Pattern 1 - simple longjmp.  */
-  if (setjmp (env) == 0) /* patt1 */
+  if (setjmp (env) != 0) /* patt1 */
     {
-      longjmps++;
-      longjmp (env, 1);
+      resumes++;
     }
   else
     {
-      resumes++;
+      longjmps++;
+      longjmp (env, 1);
     }

   i = 1; /* miss_step_1 */
...
we can avoid getting lucky on x86_64, and get the same result as for
powerpc64le.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29850

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> However, I noticed when trying the same on x86_64:
> ...
> (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
> next^M
> 56            resumes++;^M
> (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
> ...
> which is a nicer failure mode, given that we stop at the first line after
> the longjmp target.
> 

And that's the failure mode reported in PR26967.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29850

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> By inverting the branches:
> ...
> diff --git a/gdb/testsuite/gdb.base/longjmp.c
> b/gdb/testsuite/gdb.base/longjmp.c
> index 4139e49e6f1..ce6990ca99a 100644
> --- a/gdb/testsuite/gdb.base/longjmp.c
> +++ b/gdb/testsuite/gdb.base/longjmp.c
> @@ -46,14 +46,14 @@ main ()
>    volatile int i = 0;
>  
>    /* Pattern 1 - simple longjmp.  */
> -  if (setjmp (env) == 0) /* patt1 */
> +  if (setjmp (env) != 0) /* patt1 */
>      {
> -      longjmps++;
> -      longjmp (env, 1);
> +      resumes++;
>      }
>    else
>      {
> -      resumes++;
> +      longjmps++;
> +      longjmp (env, 1);
>      }
>  
>    i = 1; /* miss_step_1 */
> ...
> we can avoid getting lucky on x86_64, and get the same result as for
> powerpc64le.

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6e41445bb006f3afc784862f8eb1bf0f2691a94a

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29850

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> (In reply to Tom de Vries from comment #1)
> > By inverting the branches:
> > ...
> > diff --git a/gdb/testsuite/gdb.base/longjmp.c
> > b/gdb/testsuite/gdb.base/longjmp.c
> > index 4139e49e6f1..ce6990ca99a 100644
> > --- a/gdb/testsuite/gdb.base/longjmp.c
> > +++ b/gdb/testsuite/gdb.base/longjmp.c
> > @@ -46,14 +46,14 @@ main ()
> >    volatile int i = 0;
> >  
> >    /* Pattern 1 - simple longjmp.  */
> > -  if (setjmp (env) == 0) /* patt1 */
> > +  if (setjmp (env) != 0) /* patt1 */
> >      {
> > -      longjmps++;
> > -      longjmp (env, 1);
> > +      resumes++;
> >      }
> >    else
> >      {
> > -      resumes++;
> > +      longjmps++;
> > +      longjmp (env, 1);
> >      }
> >  
> >    i = 1; /* miss_step_1 */
> > ...
> > we can avoid getting lucky on x86_64, and get the same result as for
> > powerpc64le.
> 
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;
> h=6e41445bb006f3afc784862f8eb1bf0f2691a94a

And now that that's fixed, x86_64 fails the same as powerpc64le, so marking
this a dup of PR26967.

*** This bug has been marked as a duplicate of bug 26967 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.