Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Aditya Vidyadhar Kamath <akamath996@gmail.com>
To: ulrich.weigand@de.ibm.com, simon.marchi@polymtl.ca, tom@tromey.com
Cc: gdb-patches@sourceware.org, Aditya.Kamath1@ibm.com,
	sangamesh.swamy@in.ibm.com,
	Aditya Vidyadhar Kamath <aditya.kamath1@ibm.com>
Subject: [PATCH v3] Accept ksh88 exit status for SIGINT in shell.exp
Date: Thu, 22 Oct 2026 12:21:38 +0530	[thread overview]
Message-ID: <20261022065137.34658-2-akamath996@gmail.com> (raw)

From: Aditya Vidyadhar Kamath <aditya.kamath1@ibm.com>

This patch is in continuation to Simon's patch [1].

gdb.base/shell.exp runs "kill -2 $$" under the shell, through both
"shell" ("!") and "pipe" ("|"), and expects $_shell_exitsignal to be 2
and $_shell_exitcode to be void, that is, a shell that dies from the
signal.

On AIX, /bin/sh and /usr/bin/ksh are ksh88.  ksh88 catches SIGINT and
calls exit (130) (128 + SIGINT) instead of dying from the signal.  GDB
therefore sees a normal exit, sets $_shell_exitcode to 130 and leaves
$_shell_exitsignal void.  This is correct reporting by GDB; the test
assumes a shell that is killed by the signal.  The raw wait status of
the shells on AIX 7.3 is:

  /usr/bin/ksh    exited, code 130
  /usr/bin/ksh93  killed by signal 2
  /usr/bin/bash   killed by signal 2

As a result these four tests failed on AIX:

  shell interrupt exitcode
  shell interrupt exitsignal
  pipe interrupt exitcode
  pipe interrupt exitsignal

Add check_shell_interrupt_status and shell_dies_from_sigint:
- For "shell", the probed shell is $SHELL (or /bin/sh if not set).
- For "pipe", the probed shell is /bin/sh (since popen(3) hardcodes /bin/sh).
- If testing with a remote host ([is_remote host]), skip the local
  Tcl exec probe and assume the shell dies from SIGINT.

On shells like AIX ksh88, it accepts $_shell_exitcode = 130 together with
$_shell_exitsignal = void.

Tested on AIX 7.3 with a 64-bit GDB under ksh88, ksh93, and bash:
gdb.base/shell.exp gives 125 passes and no failures.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=bf842a2e8d6e9eb7429444904b1b31c8b85d5fb2
---
 gdb/testsuite/gdb.base/shell.exp | 59 +++++++++++++++++++++++++++++---
 1 file changed, 55 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.base/shell.exp b/gdb/testsuite/gdb.base/shell.exp
index 2e6c63585eb..e1a3fe85d29 100644
--- a/gdb/testsuite/gdb.base/shell.exp
+++ b/gdb/testsuite/gdb.base/shell.exp
@@ -17,6 +17,59 @@
 
 load_lib completion-support.exp
 
+# Not every shell reacts to "kill -2 $$" the same way.  Most are killed
+# by the signal, but ksh88 (/bin/sh and /usr/bin/ksh on AIX) catches
+# SIGINT and exits with status 130 (128 + SIGINT) instead.  GDB reports
+# what it sees, so in that case $_shell_exitcode is 130 and
+# $_shell_exitsignal is void.
+#
+# Find out which kind of shell we have by running it the same way GDB
+# would.  Return true if the shell is killed by the signal, and false if
+# it exits with status 130.
+
+proc shell_dies_from_sigint { shell } {
+    if { [is_remote host] } {
+	return 1
+    }
+
+    if { [catch {exec $shell -c {kill -2 $$}} msg opts] } {
+	set errcode [dict get $opts -errorcode]
+	if { [lindex $errcode 0] eq "CHILDSTATUS"
+	     && [lindex $errcode 2] == 130 } {
+	    return 0
+	}
+    }
+
+    return 1
+}
+
+# Check the convenience variables after a shell command that ran
+# "kill -2 $$".  PREFIX is "shell" or "pipe", and is used to name the
+# tests.
+
+proc check_shell_interrupt_status { prefix } {
+    if { $prefix eq "shell" } {
+	set shell /bin/sh
+	if { [info exists ::env(SHELL)] } {
+	    set shell $::env(SHELL)
+	}
+    } elseif { $prefix eq "pipe" } {
+	# pipe uses popen, which hardcodes /bin/sh.
+	set shell /bin/sh
+    } else {
+	error "Unknown prefix: $prefix"
+    }
+
+    if { [shell_dies_from_sigint $shell] } {
+	gdb_test "p \$_shell_exitcode" " = void" "$prefix interrupt exitcode"
+	gdb_test "p \$_shell_exitsignal" " = 2" "$prefix interrupt exitsignal"
+    } else {
+	gdb_test "p \$_shell_exitcode" " = 130" "$prefix interrupt exitcode"
+	gdb_test "p \$_shell_exitsignal" " = void" \
+	    "$prefix interrupt exitsignal"
+    }
+}
+
 gdb_exit
 gdb_start
 
@@ -37,8 +90,7 @@ gdb_test "p \$_shell_exitsignal" " = void" "shell fail exitsignal"
 # This test will not work when the shell is CMD.EXE.
 if { ! [ishost *-*-mingw*] } {
     gdb_test_no_output "! kill -2 $$"
-    gdb_test "p \$_shell_exitcode" " = void" "shell interrupt exitcode"
-    gdb_test "p \$_shell_exitsignal" " = 2" "shell interrupt exitsignal"
+    check_shell_interrupt_status "shell"
 }
 
 # Test the $_shell convenience function.
@@ -130,8 +182,7 @@ gdb_test "p \$_shell_exitsignal" " = void" "pipe fail exitsignal"
 # This test will not work when the shell is CMD.EXE.
 if { ! [ishost *-*-mingw*] } {
     gdb_test "|p 123| kill -2 $$" ""
-    gdb_test "p \$_shell_exitcode" " = void" "pipe interrupt exitcode"
-    gdb_test "p \$_shell_exitsignal" " = 2" "pipe interrupt exitsignal"
+    check_shell_interrupt_status "pipe"
 }
 
 # Error handling verifications.
-- 
2.51.2


                 reply	other threads:[~2026-10-22  6:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261022065137.34658-2-akamath996@gmail.com \
    --to=akamath996@gmail.com \
    --cc=Aditya.Kamath1@ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.com \
    --cc=simon.marchi@polymtl.ca \
    --cc=tom@tromey.com \
    --cc=ulrich.weigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox