public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
* [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) @ 2022-12-05 9:02 vries at gcc dot gnu.org 2022-12-05 10:00 ` [Bug gdb/29850] " vries at gcc dot gnu.org ` (3 more replies) 0 siblings, 4 replies; 5+ messages in thread From: vries at gcc dot gnu.org @ 2022-12-05 9:02 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) 2022-12-05 9:02 [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org @ 2022-12-05 10:00 ` vries at gcc dot gnu.org 2022-12-05 10:03 ` vries at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 5+ messages in thread From: vries at gcc dot gnu.org @ 2022-12-05 10:00 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) 2022-12-05 9:02 [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org 2022-12-05 10:00 ` [Bug gdb/29850] " vries at gcc dot gnu.org @ 2022-12-05 10:03 ` vries at gcc dot gnu.org 2022-12-06 11:04 ` vries at gcc dot gnu.org 2022-12-07 8:33 ` vries at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: vries at gcc dot gnu.org @ 2022-12-05 10:03 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) 2022-12-05 9:02 [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org 2022-12-05 10:00 ` [Bug gdb/29850] " vries at gcc dot gnu.org 2022-12-05 10:03 ` vries at gcc dot gnu.org @ 2022-12-06 11:04 ` vries at gcc dot gnu.org 2022-12-07 8:33 ` vries at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: vries at gcc dot gnu.org @ 2022-12-06 11:04 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/29850] [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) 2022-12-05 9:02 [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org ` (2 preceding siblings ...) 2022-12-06 11:04 ` vries at gcc dot gnu.org @ 2022-12-07 8:33 ` vries at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: vries at gcc dot gnu.org @ 2022-12-07 8:33 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-07 8:33 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-05 9:02 [Bug gdb/29850] New: [gdb, powerpc64le] FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org 2022-12-05 10:00 ` [Bug gdb/29850] " vries at gcc dot gnu.org 2022-12-05 10:03 ` vries at gcc dot gnu.org 2022-12-06 11:04 ` vries at gcc dot gnu.org 2022-12-07 8:33 ` vries at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).