public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [pushed 1/2] [gdb/testsuite] Make gdb.base/longjmp.exp FAIL more stable across archs
@ 2022-12-06 11:02 Tom de Vries
  2022-12-06 11:02 ` [pushed 2/2] [gdb/testsuite] Fix test names in gdb.base/longjmp.exp Tom de Vries
  0 siblings, 1 reply; 2+ messages in thread
From: Tom de Vries @ 2022-12-06 11:02 UTC (permalink / raw)
  To: gdb-patches

When running test-case gdb.base/longjmp.exp on x86_64-linux, the master
longjmp breakpoint is set using probes and the test-case passes:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
0x00000000004005cc      49        if (setjmp (env) == 0) /* patt1 */^M
(gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1)
next^M
56            resumes++;^M
(gdb) PASS: gdb.base/longjmp.exp: next into else block (1)
...

However, if I disable
create_longjmp_master_breakpoint_probe, we have instead:
...
(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)
...

At first glance, the failure mode doesn't look too bad: we stop
a few insns later than the passing scenario.

For contrast, if we do the same on powerpc64le, the failure mode is:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
^M
Breakpoint 3, main () at longjmp.c:59^M
59        i = 1; /* miss_step_1 */^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
Here we only stop because of running into the safety net breakpoint at
miss_step_1.

So, how does this happen on x86_64?  Let's look at the code:
...
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>
...
The next over the longjmp call at 4005e9 is supposed to stop at the longjmp
target at 4005cc, but instead we stop at 4005ee, where we have the step-resume
breakpoint inserted by the next.  In other words, we accidentally "return"
from the longjmp call to the insn immediately after it (even though
a longjmp is a noreturn function).

Try to avoid this accident and make the failure mode on x86_64 the same as on
powerpc64le, by switching the then and else branch.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.base/longjmp.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

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 */

base-commit: c8ea5e409b02cf7fa848e44af74b2e8246ad03f1
-- 
2.35.3


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-12-06 11:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-06 11:02 [pushed 1/2] [gdb/testsuite] Make gdb.base/longjmp.exp FAIL more stable across archs Tom de Vries
2022-12-06 11:02 ` [pushed 2/2] [gdb/testsuite] Fix test names in gdb.base/longjmp.exp Tom de Vries

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