From: Tom de Vries Date: Fri, 19 Jan 2024 16:40:03 +0000 (+0100) Subject: [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp X-Git-Tag: gdb-15-branchpoint~1200 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=92517d01fe5b4286b2dcb04cfcda0a2b5bd52adb;p=thirdparty%2Fbinutils-gdb.git [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into: ... (gdb) attach 7773^M Attaching to program: attach-many-short-lived-threads, process 7773^M Cannot attach to lwp 7776: Operation not permitted (1)^M (gdb) PASS: $exp: iter 1: attach info threads^M No threads.^M (gdb) PASS: $exp: iter 1: no new threads set breakpoint always-inserted on^M (gdb) PASS: $exp: iter 1: set breakpoint always-inserted on break break_fn^M Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M (gdb) PASS: $exp: iter 1: break break_fn continue^M The program is not being run.^M (gdb) FAIL: $exp: iter 1: break at break_fn: 1 \ (the program is no longer running) ... There's some code in the test-case dealing with a similar warning: ... -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { ... But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be traced"), the warning has been changed into an error. Fix the FAIL by updating the test-case to expect an error instead of a warning. Tested on x86_64-linux. Approved-By: Tom Tromey --- diff --git a/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp b/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp index 3fdadf9827f..6bee0ad2e2c 100644 --- a/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp +++ b/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp @@ -74,7 +74,7 @@ proc test {} { # Seen when "set debug libthread_db" is on. exp_continue } - -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { + -re "Cannot attach to lwp $decimal: Operation not permitted" { # On Linux, PTRACE_ATTACH sometimes fails with # EPERM, even though /proc/PID/status indicates # the thread is running. @@ -96,6 +96,10 @@ proc test {} { } } + if { $eperm } { + continue + } + # Sleep a bit and try updating the thread list. We should # know about all threads already at this point. If we see # "New Thread" or similar being output, then "attach" is