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

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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.