From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=MNIR=4R=gmail.com=jcb62281@sourceware.org>
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f])
	by sourceware.org (Postfix) with ESMTPS id 40FCD3AF8370;
	Mon, 19 Dec 2022 04:29:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40FCD3AF8370
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-1445ca00781so10234617fac.1;
        Sun, 18 Dec 2022 20:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:references:subject:cc:to
         :mime-version:user-agent:reply-to:from:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=riwcaOtaWPOOQZEtgjJ7vYGYK9hcE4VkW21uAFuksrI=;
        b=XYNgdfzGA9TSfs9KS/pyecB4Yatpq5WX9Ycnqv0QsCPLw4QYJ71CrnMCLvAsoA2YOJ
         Zs28nbiDaQuJ0ep5I2VOM2ohuc06zADgD2fdMUpur2kKxyxZxmRDp2qCNVDCoo+BEtmn
         8Dw9gkIBCKk8dvZIGz1vMU9yzO9fX3hxVcwI9Pip6EFPpxjH9UP8cwHBjs1ZTGFnbYrG
         m+9RQ0FBnEOeVh8eaOsmedwVnvMU5S4wmyywD2fvQe4sGdERsoQTRhGmAGHVKJfNUxFm
         f6OSiREtSLawwzaMUaAuOwvihHY9Tlmf5dgtdC3Er/0HTtkR9+ogAzLWgFWYMNT8EYyh
         GNMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:references:subject:cc:to
         :mime-version:user-agent:reply-to:from:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=riwcaOtaWPOOQZEtgjJ7vYGYK9hcE4VkW21uAFuksrI=;
        b=Moog4WCHuUMyf+ISiLPtafUU9UFCLOVEN5nElIlF7YIta/5qp1qxI2NN5dp3tI87U5
         Pj8JS6XWQwVtKgUoJ/uD3Kg0gOERJuKciE+p+7ZdWtcGrbh5zrZbXSAa46IpaN6o29Uf
         YH/UfqvlSWD/PllQ7GBa8NKRvLW3LGF6/9lBcHjrvufK6j5gVXR0WdNSqzmvfzBE/vRf
         3oYEh/2Su4Ni5rfdDJYL/dXsqZ4siR5YETMPu+cX0WM/Y6lpZ/5jktt6xUJ31paeSf2h
         Ttqi/snXDzwxxGXxwKhcnLPKngW98hmsGmkBsQy7ZZHu/5MzTq1w4/AVuDhlrATCcKOf
         vrQw==
X-Gm-Message-State: AFqh2krviP7nDA7OrwiQPIlbR8NV5Oh66u2nrtcS+6EQ5R1wqcDjeQvj
	zidouGbydlf7Qy4CTyH7cuI=
X-Google-Smtp-Source: AMrXdXt1q0BjcdoT0cwbzbOonJf/cWoXRv8kAK4qfVSeVlbPcOxNxdnIrydpojvhCAJrfEXf20PCiQ==
X-Received: by 2002:a05:6870:d10f:b0:14c:37e7:207d with SMTP id e15-20020a056870d10f00b0014c37e7207dmr376910oac.16.1671424145305;
        Sun, 18 Dec 2022 20:29:05 -0800 (PST)
Received: from [127.0.0.1] ([70.133.144.146])
        by smtp.gmail.com with ESMTPSA id cy19-20020a056870b69300b00143065d3e99sm4252450oab.5.2022.12.18.20.29.04
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Sun, 18 Dec 2022 20:29:04 -0800 (PST)
Message-ID: <639FE88D.7090408@gmail.com>
Date: Sun, 18 Dec 2022 22:29:01 -0600
From: Jacob Bachmeyer <jcb62281@gmail.com>
Reply-To: jcb62281@gmail.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: NightStrike <nightstrike@gmail.com>
CC: Thomas Koenig <tkoenig@netcologne.de>, 
 "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
 gcc mailing list <gcc@gcc.gnu.org>, dejagnu@gnu.org
Subject: Re: testsuite under wine
References: <CAF1jjLtJW0juQR6L-VybJ8SSaqkfi=qN9FnxJVaY=oQBtkSLxA@mail.gmail.com> <3f62bac2-ac1b-5c55-2488-ede2389d35d2@netcologne.de> <CAF1jjLvJU2fnU0u0p9SwPre5mnhFdmv9pm_OvZGOvjQApCROqw@mail.gmail.com> <19a6b738-ad34-d145-1202-d2c7c474b272@netcologne.de> <CAF1jjLta5N5uXQKbgTN0CyKYu3PzXnPRPJArjiuUcxLqCkbehQ@mail.gmail.com> <639E8CB3.4030109@gmail.com> <CAF1jjLu_4vTmVk_KbaCmHf-Lqcwvz2fX5=RvGFB6Y3MCUBDngg@mail.gmail.com>
In-Reply-To: <CAF1jjLu_4vTmVk_KbaCmHf-Lqcwvz2fX5=RvGFB6Y3MCUBDngg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc.gcc.gnu.org>

NightStrike wrote:
> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> [...]
>> This is either a testsuite problem or an environment problem.  The GNU
>> Fortran I/O module certainly has interesting behavior here.  Try setting
>> TERM=dumb in the environment while running the testsuite.  If that fixes
>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
>> tool init file for GNU Fortran.
>>     
>
> Setting TERM doesn't help.  Wine tries to emulate the windows console,
> which requires outputting this stuff.  It does so any time there's a
> pty, and I believe that Deja creates a pty when running the tests.
>   

That is a bug in Wine:  the escapes should be suppressed entirely if the 
terminal does not support them---and the "dumb" terminal does not 
support them.

> Wine people suggested if I could somehow run the test as "wine ./a.exe
> | cat", that it would prevent this behavior, but I couldn't find a way
> to do that.

Actually... I think you can, as long as the programs to be run do not 
require input, but you will need to modify the testsuite to spawn 
programs differently when using Wine.  There is probably a "spawn" 
command somewhere in the testsuite.  You will want to change that to add 
a conditional for cross-testing using Wine and to use a pipeline in that 
case.  Something like:

8<------
if { ![isnative] && ![isremote target] && [istarget *-*-mingw*] } { # or similar pattern
    spawn -open [open "| wine ${command} </dev/null" r]
} else {
    # the original "spawn" command
    spawn $command
}
8<------


If these are "dg" tests, the code you need to change should be in the 
${tool}_load procedure in the tool init file, most likely in 
testsuite/lib.  Again, this can work only if the test programs are 
non-interactive, since Tcl does not allow running a subprocess with both 
input and output on pipes connected to the main program.  (Expect does, 
but uses a pty instead of a pair of pipes to accomplish this.)  The 
above example connects the child process's stdin to /dev/null and its 
stdout to a pipe to the Tcl interpreter running the testsuite; Expect 
then wraps the file handle in an Expect spawn handle and the rest of the 
code can use the 'expect' command as normal to read its output.

Also, "wine" should probably be instead a global variable WINE that can 
be set to a specific Wine executable if needed, but the best long-term 
solution is probably to fix the console emulation in Wine.

There may be more layers of indirection involved, possibly back into the 
framework; I am somewhat less familiar with the details of the GCC 
testsuite, so it would be very helpful if you could point me to one of 
the tests in question.  This may turn into a feature request for general 
framework support for emulated targets using "interposition emulators" 
such as Wine or QEMU.  I will think about that, but it probably will not 
be in 1.6.4.

>   For now, I modified Wine to kludge out the code that
> creates the console, and a long term solution needs to be on the Wine
> side.  I was just hoping for a less dirty hack from the Deja side.
>   

I think that the long-term solution is that Wine should properly honor 
the TERM environment variable and not produce escape codes that the 
declared terminal does not support.

> Note that there are other problems, too.  It seems that when Deja is
> matching against "\n", it doesn't handle the different line endings of
> Windows correctly in a cross environment.  Is there a way that I can
> set how to interpret \n in a target-board file?  This affects fortran
> and other language tests also.

No---problems related to line endings are bugs in the testsuite.  This 
caveat is documented in *Note: (dejagnu)Writing a test case.  The manual 
explains:  "Note that terminal settings may result in the insertion of 
additional `\r' characters, usually translating `\n' to `\r\n'."

At the terminal layer, POSIX can *also* use "\r\n" sequences, since some 
terminals historically needed them, even though the standard line ending 
*within* a POSIX system is "\n" by itself.  Because a pty simply 
presents the "terminal" side of the interface to the controlling 
program, Expect can receive "\r\n" when the subprocess emits "\n"; the 
translation is performed by the kernel terminal driver and DejaGnu 
testsuites must be prepared to receive (and discard) excess carriage 
returns in the general case.


-- Jacob