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).