dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testsuite under wine


From: Jacob Bachmeyer
Subject: Re: testsuite under wine
Date: Sun, 18 Dec 2022 22:29:01 -0600
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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]