From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6o8xCX3bE2qCWRcAWB0awg (envelope-from ) for ; Mon, 25 May 2026 01:17:49 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=d7vBTE0T; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 13B3E1E0A3; Mon, 25 May 2026 01:17:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2DA0C1E062 for ; Mon, 25 May 2026 01:17:48 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0D8AA4BABF03 for ; Mon, 25 May 2026 05:17:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D8AA4BABF03 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=d7vBTE0T Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id E060F4BA9003 for ; Mon, 25 May 2026 05:17:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E060F4BA9003 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E060F4BA9003 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779686240; cv=none; b=O7FXmnskdGYO6O0FmoE5HLIXwEl7xqsv57T/o7TUGf7AcmvKnjTd4czMHl5qGcrdHH3niByWYKHoTNDLykYQ0/WeRxt5AaHCfjEmSDQX5t/A6z2Af4qrUsF1rup+3fck+Sg06XVTYDltUifrs+AIqhE+ix83ihWTU2q/aJz/WpM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779686240; c=relaxed/simple; bh=sQdoAei2cwSwvDKegcBnquV/IY9SUNblMwegeMRRPJU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=r4Sl9tVh6SjBGWEwwiqUhc/mmtw7e9kjbXSUSMH6rOsPCtNyUW3kJPt9yJ07ZHWAbOPpnKJwkVyR0baZ3b8HivzaybIO9ROMSkhVYhoi06l2CSSl4lC6HEVpujEM/Av6M1+FYfIV7cL0DWc2Mhp5/ZVB3a8oAoilnZNA5kvpLdg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=d7vBTE0T DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E060F4BA9003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779686239; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jV94grOlS6bnhkiFpiSPiEN0VUnSHjf7lF5joWZHas4=; b=d7vBTE0TfDMrbeiltBRoxTa84ch+r6E6ex5QGXnXAxRx8Tq/SefqVPNtoiFm4l4iZb3Ysx p6/fbhQs5A/gE+IvNGT/pW4Dxc3LvSTP6O58qQpsJfr5To2XUM3KxL5M9858D1GfoEL7sD RXX/+Qd/zipxuKVShIdkFuA9ybMEN68= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-593-5z8gmrs7Mc6G3IYN4kW0kQ-1; Mon, 25 May 2026 01:17:17 -0400 X-MC-Unique: 5z8gmrs7Mc6G3IYN4kW0kQ-1 X-Mimecast-MFC-AGG-ID: 5z8gmrs7Mc6G3IYN4kW0kQ_1779686236 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BCA7C18005B8 for ; Mon, 25 May 2026 05:17:16 +0000 (UTC) Received: from f44-1.lan (unknown [10.22.64.64]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0FF0B19560A3; Mon, 25 May 2026 05:17:15 +0000 (UTC) From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Kevin Buettner Subject: [PATCH] [gdb/testsuite, Tcl 9] Fix EILSEQ problems for UTF8 related tests Date: Sun, 24 May 2026 22:14:43 -0700 Message-ID: <20260525051442.2805651-2-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _I4YdwaCKBZE3HOBOBESm9fyqLZZIP1keXrFwNFNPe8_1779686236 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Fedora 44 and Rawhide (Fedora 45), these tests... gdb.ada/non-ascii-utf-8.exp gdb.base/utf8-identifiers.exp gdb.rust/unicode.exp ...all die due to these errors: Running ...gdb/testsuite/gdb.base/utf8-identifiers.exp ... ERROR: tcl error sourcing .../gdb/testsuite/gdb.base/utf8-identifiers.exp. ERROR: tcl error code POSIX EILSEQ {invalid or incomplete multibyte or wide character} error writing "file6": invalid or incomplete multibyte or wide character ... (I've shortened some of the pathnames for brevity.) These Fedora systems are using Tcl 9 and also an updated version of dejagnu with this change applied: * Thu Apr 16 2026 Jakub Jelinek - 1:1.6.3-17 - Apply full set of Tcl 9 compatibility fixes from upstream PR80674 branch (#2448542) That runtest change is responsible for the POSIX EILSEQ errors on machines with that change. The change to runtest causing the change in behavior for GDB is the addition of these lines near the top of the runtest script: # Ensure that DejaGnu will be run in the POSIX locale LC_ALL=C export LC_ALL TCL 8 used a permissive encoding strategy: bytes that could not be represented in the current encoding were silently mangled or substituted. TCL 9 changed this default to a strict profile, which means that any attempt to write a character that cannot be expressed in the channel's encoding raises a POSIX EILSEQ error ("invalid or incomplete multibyte or wide character"). So, together, this Tcl 9 behavior combined with the dejagnu change to runtest causes the EILSEQ error for the tests mentioned earlier. Fix it by using "fconfigure $handle -encoding utf-8 -profile replace" in proc spawn_capture_tty_name, and proc gdb_stdin_log_init. Also, the open_logs wrapper has been changed to invoke fconfigure using only "-encoding utf-8". Testing showed that "-profile replace" wasn't necessary there. Tested on Fedora 28 (Tcl 8.6.8), Fedora 43 (Tcl 9.0.2 / 8.6.16; expect uses 8.6.16), Fedora 44 (Tcl 9.0.2 / 8.6.17; expect uses 9.0.2), and Rawhide / Fedora 45 (Tcl 9.0.3 / 8.6.18; expect uses 9.0.3). --- gdb/testsuite/lib/gdb.exp | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 28709004570..52e4be9122d 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -166,6 +166,27 @@ proc load_lib { file } { return $result } +# Tcl 9.0 changed the default channel encoding profile to "strict". When +# runtest sets LC_ALL=C the system encoding is iso8859-1, so file channels +# opened by DejaGNU (gdb.sum, gdb.log) and spawn channels (for GDB and +# subprocesses) default to iso8859-1 with strict profile. Writing +# non-Latin-1 characters in test names then raises EILSEQ, and sending them +# to GDB truncates the command at the unrepresentable character. +# +# Fix this by: +# 1. Overriding open_logs to reconfigure gdb.sum to utf-8 after DejaGNU +# opens it with the system (iso8859-1) encoding. +# 2. Reconfiguring each new spawn channel to utf-8 in +# spawn_capture_tty_name, which wraps every spawn call. +# 3. Reconfiguring gdb.in to utf-8 in gdb_stdin_log_init. + +rename open_logs saved_open_logs +proc open_logs {} { + saved_open_logs + global sum_file + fconfigure $sum_file -encoding utf-8 +} + load_lib libgloss.exp load_lib cache.exp load_lib gdb-utils.exp @@ -2633,6 +2654,7 @@ proc gdb_file_cmd { arg {kill_flag 1} } { proc spawn_capture_tty_name { args } { set result [uplevel builtin_spawn $args] upvar spawn_out spawn_out + upvar spawn_id spawn_id if { [info exists spawn_out(slave,name)] } { set ::last_spawn_tty_name $spawn_out(slave,name) } else { @@ -2648,6 +2670,12 @@ proc spawn_capture_tty_name { args } { # use -nocomplain here we would otherwise get an error. unset -nocomplain ::last_spawn_tty_name } + # Tcl 9.0 defaults spawn channels to iso8859-1/strict, which raises + # EILSEQ when non-Latin-1 characters (e.g. function names with UTF-8 + # letters) are written to or read from the channel. Use utf-8 instead. + if {[tcl_version_at_least 9 0 0]} { + catch {fconfigure $spawn_id -encoding utf-8 -profile replace} + } return $result } @@ -10419,6 +10447,11 @@ proc gdb_stdin_log_init { } { set logfile [standard_output_file_with_gdb_instance gdb.in] set in_file [open $logfile w] + if {[tcl_version_at_least 9 0 0]} { + # Tcl 9 strict profile: gdb.in must accept UTF-8 command strings. + fconfigure $in_file -encoding utf-8 -profile replace + } + verbose -log "" verbose -log "Starting logfile: $logfile" verbose -log "" -- 2.54.0