From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RROxCK70FWrIMB4AWB0awg (envelope-from ) for ; Tue, 26 May 2026 15:29:50 -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=hV4U4k/S; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 116DE1E0A3; Tue, 26 May 2026 15:29:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 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_SBL_CSS,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 396831E024 for ; Tue, 26 May 2026 15:29:49 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 915654BA23D6 for ; Tue, 26 May 2026 19:29:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 915654BA23D6 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=hV4U4k/S Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id CA51F4BA2E29 for ; Tue, 26 May 2026 19:29:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA51F4BA2E29 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 CA51F4BA2E29 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779823761; cv=none; b=hve+Buy+n8R1A9uTqiy72a1517WSlfMoHIcgW4HrV0uIcBqoC126pwV5n8msXFO+VZHH/Zkyhpi+c6Yk5bvKC9JhM+3b0t/KMdmsC41GrlchmeYWmD1CeckB+zPK3Ggka0Jy8zfckHPxfE8cwmpJKrdx4pVceZK6NswWFR7ilvo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779823761; c=relaxed/simple; bh=h68Klwl9dIV7JphUUbgwBipN496dRby2l5GVGTEyCNw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=k+DAlqT4V5/llhR9stJNbK7PhS87x7fhcrRJiEyeF5E0pse1ykR+45YhskCoL9Hv2ahsJQrktu2pcpOPWuURnWW4nz981PCSFuw9a2WUSrkZI5AU878h07H7c0bGTVFyK4AT85atUxvgDplKT/tcQntnztX72dp/d12ae9jOXjU= 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=hV4U4k/S DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA51F4BA2E29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779823761; 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=d1PF0cCpHQlj30KyU7QFU1WUP72b7hihaRAJVy1WMBQ=; b=hV4U4k/S0WTfABrinx/tYcilCe1sRjj3ROTFefiVGAh+5NiRBLs6iAqrjK+fWgf4T0wrpq gEObLtG/J0zBAMgWqIscSI+ob93HzZ27DO5Iw4rIYmpQKpjVZ2Lp13HwQtlRRX7Gkpu5pH zJci+gPNEBCd1vMV+pAkP3qj/xRIILY= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-ThWQtvcbNzeLwtPQzVs0mg-1; Tue, 26 May 2026 15:29:16 -0400 X-MC-Unique: ThWQtvcbNzeLwtPQzVs0mg-1 X-Mimecast-MFC-AGG-ID: ThWQtvcbNzeLwtPQzVs0mg_1779823754 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7EE7719560A5; Tue, 26 May 2026 19:29:13 +0000 (UTC) Received: from f44-1.lan (unknown [10.22.64.64]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7C0821800352; Tue, 26 May 2026 19:29:12 +0000 (UTC) From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Kevin Buettner , Tom de Vries Subject: [PATCH v2] [gdb/testsuite, Tcl 9] Fix EILSEQ problems for UTF8 related tests Date: Tue, 26 May 2026 12:27:02 -0700 Message-ID: <20260526192701.3835262-2-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 90kqT5WUwko_O2fFfN95Vvh6V3IClG8xJvGhd_zWn6E_1779823754 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). With regard to the Bug noted below, I haven't been able to reproduce the failures in gdb.ada/lazy-string.exp, but I've been informed that this commit fixes it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34146 Reviewed-By: Tom de Vries --- gdb/testsuite/lib/gdb.exp | 50 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 28709004570..caf37b0608d 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -166,6 +166,35 @@ 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. Only +# "-encoding utf-8" is needed here, not "-profile replace". The +# test names written to gdb.sum are Unicode strings, and since +# UTF-8 can represent every Unicode character, the encode +# operation cannot fail. This use of "fconfigure" lacks a Tcl +# version guard since "-encoding utf-8" works in both Tcl 8 and +# Tcl 9. (Use of "-profile replace" requires a guard, as that +# option did not exist before Tcl 9.) +# 2. Reconfiguring each new spawn channel to UTF-8 and to also use +# "-profile replace" in spawn_capture_tty_name, which wraps every +# spawn call. +# 3. Likewise for gdb_stdin_log_init. + +rename open_logs saved_open_logs +proc open_logs {} { + saved_open_logs + fconfigure $::sum_file -encoding utf-8 +} + load_lib libgloss.exp load_lib cache.exp load_lib gdb-utils.exp @@ -2633,6 +2662,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 +2678,21 @@ 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. identifiers + # with UTF-8 letters) are written to or read from the channel. + # Use utf-8 instead. + # + # "catch" is used here because, unlike the other sites in this + # file where fconfigure is used, this use of fconfigure could + # attempt to modify channels which do not support these options. + # Those other sites use "fconfigure" on recently opened files + # where it will almost certainly work. (And, for those other sites, + # if it doesn't work, we want to be notified of that fact via the + # normal Tcl error reporting mechanisms.) + if {[tcl_version_at_least 9 0 0]} { + catch {fconfigure $spawn_id -encoding utf-8 -profile replace} + } return $result } @@ -10419,6 +10464,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