Re: testsuite under wine

[Jacob Bachmeyer <jcb62281@gmail.com>]

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