* testsuite under wine @ 2022-12-16 2:20 NightStrike 2022-12-16 6:44 ` Thomas Koenig 0 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-16 2:20 UTC (permalink / raw) To: fortran When I run the testsuite under wine, I'm getting a lot of ANSI escape sequences. We had fixed this long ago, but it seems to be back. Any idea what I should change in my configuration to have this not happen? This is for build=host=x86_64-pc-linux-gnu and target=x86_64-w64-mingw32, with the testsuite running under wine64 v7.20. Example output, where you can see the output in between the escape sequences is correct: FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -Os output pattern test Output was: ^[[?25lC^[[?25h^[[?25lF^[[?25h^[[?25lI^[[?25h^[[?25l_^[[?25h^[[?25ls^[[?25h^[[?25le^[[?25h^[[?25lt^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h ^[[?25lt^[[?25h^[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lR^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lu^[[?25h^[[?25ll^[[?25h^[[?25l t^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25ls^[[?25h^[[?25lh^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25ll^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lb^[[?25h^[[?25le^[[?25h^[[?25 l^[[K^[[1C^[[?25h^[[?25lt^[[?25h^[[?25lh^[[?25h^[[?25le^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25ld^[[?25h^[[?25ld^[[?25h^[[?25lr^[[?25h^[[?25le^[[?25h^[[?2 5ls^[[?25h^[[?25ls^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lo^[[?25h^[[?25lf^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lC^[[?25h^[[?25l^[[K ^[[1C^[[?25h^[[?25ld^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lc^[[?25h^[[?25lr^[[?25h^[[?25li^[[?25h^[[?25lp^[[?25h^[[?25lt^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[ ?25l^[[K^[[1C^[[?25h^[[?25lf^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lF^[[?25h^[[?25lo^[[?25h^[[?25lr^ [[?25h^[[?25lt^[[?25h^[[?25lr^[[?25h^[[?25la^[[?25h^[[?25ln^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h^[[?25lt^[[?25h^ [[?25le^[[?25h^[[?25lr^[[?25h^[[?25l.^[[?25h^M^M Should match: CFI_setpointer: Result shall be the address of a C descriptor for a Fortran pointer. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-16 2:20 testsuite under wine NightStrike @ 2022-12-16 6:44 ` Thomas Koenig 2022-12-17 0:26 ` NightStrike 0 siblings, 1 reply; 44+ messages in thread From: Thomas Koenig @ 2022-12-16 6:44 UTC (permalink / raw) To: NightStrike, fortran On 16.12.22 03:20, NightStrike via Fortran wrote: > When I run the testsuite under wine, I'm getting a lot of ANSI escape > sequences. We had fixed this long ago, but it seems to be back. Any > idea what I should change in my configuration to have this not happen? This should probably be fixed properly in some *.exp file, but you can try setting the GCC_COLORS environment variable to an empty string before running the test. Regards Thomas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-16 6:44 ` Thomas Koenig @ 2022-12-17 0:26 ` NightStrike 2022-12-17 10:52 ` Thomas Koenig 0 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-17 0:26 UTC (permalink / raw) To: Thomas Koenig; +Cc: fortran On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > > On 16.12.22 03:20, NightStrike via Fortran wrote: > > > When I run the testsuite under wine, I'm getting a lot of ANSI escape > > sequences. We had fixed this long ago, but it seems to be back. Any > > idea what I should change in my configuration to have this not happen? > > This should probably be fixed properly in some *.exp file, but you can > try setting the GCC_COLORS environment variable to an empty string > before running the test. That didn't help. It looks like this is always escape 25h to start the output and 25l to end it, which I think is turning the cursor on and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I apparently fixed this previously by building wine with --without-curses (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that option to wine was removed. Is there a way to hack this on the Deja side to ignore the escapes? Or to tell it to run in a way that makes wine not emit them? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-17 0:26 ` NightStrike @ 2022-12-17 10:52 ` Thomas Koenig 2022-12-17 23:24 ` NightStrike 0 siblings, 1 reply; 44+ messages in thread From: Thomas Koenig @ 2022-12-17 10:52 UTC (permalink / raw) To: NightStrike; +Cc: fortran, gcc mailing list On 17.12.22 01:26, NightStrike wrote: > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: >> >> On 16.12.22 03:20, NightStrike via Fortran wrote: >> >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape >>> sequences. We had fixed this long ago, but it seems to be back. Any >>> idea what I should change in my configuration to have this not happen? >> >> This should probably be fixed properly in some *.exp file, but you can >> try setting the GCC_COLORS environment variable to an empty string >> before running the test. > > That didn't help. It looks like this is always escape 25h to start > the output and 25l to end it, which I think is turning the cursor on > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > apparently fixed this previously by building wine with > --without-curses > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > option to wine was removed. Is there a way to hack this on the Deja > side to ignore the escapes? Or to tell it to run in a way that makes > wine not emit them? Truth is, I don't know. I have included the gcc mailing list in this reply, where more knowledgeable people can be found :-) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-17 10:52 ` Thomas Koenig @ 2022-12-17 23:24 ` NightStrike 2022-12-18 3:44 ` Jacob Bachmeyer 0 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-17 23:24 UTC (permalink / raw) To: Thomas Koenig; +Cc: fortran, gcc mailing list, dejagnu On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > > On 17.12.22 01:26, NightStrike wrote: > > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >> > >> On 16.12.22 03:20, NightStrike via Fortran wrote: > >> > >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape > >>> sequences. We had fixed this long ago, but it seems to be back. Any > >>> idea what I should change in my configuration to have this not happen? > >> > >> This should probably be fixed properly in some *.exp file, but you can > >> try setting the GCC_COLORS environment variable to an empty string > >> before running the test. > > > > That didn't help. It looks like this is always escape 25h to start > > the output and 25l to end it, which I think is turning the cursor on > > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > > apparently fixed this previously by building wine with > > --without-curses > > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > > option to wine was removed. Is there a way to hack this on the Deja > > side to ignore the escapes? Or to tell it to run in a way that makes > > wine not emit them? > > Truth is, I don't know. > > I have included the gcc mailing list in this reply, where more > knowledgeable people can be found :-) Thanks. I'm including the dejagnu list, maybe someone there can help, too. For clarity, this is an example of what I see: Output was: ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^M^M Should match: My_R1 : 78 56 34 12.* My_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-17 23:24 ` NightStrike @ 2022-12-18 3:44 ` Jacob Bachmeyer 2022-12-18 21:13 ` NightStrike 0 siblings, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-18 3:44 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu NightStrike wrote: > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >> On 17.12.22 01:26, NightStrike wrote: >> >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: >>> >>>> On 16.12.22 03:20, NightStrike via Fortran wrote: >>>> >>>> >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape >>>>> sequences. We had fixed this long ago, but it seems to be back. Any >>>>> idea what I should change in my configuration to have this not happen? >>>>> >>>> This should probably be fixed properly in some *.exp file, but you can >>>> try setting the GCC_COLORS environment variable to an empty string >>>> before running the test. >>>> >>> That didn't help. It looks like this is always escape 25h to start >>> the output and 25l to end it, which I think is turning the cursor on >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I >>> apparently fixed this previously by building wine with >>> --without-curses >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that >>> option to wine was removed. Is there a way to hack this on the Deja >>> side to ignore the escapes? Or to tell it to run in a way that makes >>> wine not emit them? >>> >> Truth is, I don't know. >> >> I have included the gcc mailing list in this reply, where more >> knowledgeable people can be found :-) >> > > Thanks. I'm including the dejagnu list, maybe someone there can help, too. > > For clarity, this is an example of what I see: > > Output was: > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^M^M > > Should match: > My_R1 : 78 56 34 12.* > My_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > DejaGnu cannot routinely strip escape sequences because they could be part of the intended output---or strictly forbidden in the intended output. Further, I suspect that the comparison is being carried out in the testsuite code rather than the framework, but the thread that arrived on the DejaGnu list does not mention what test is failing or what testsuite is being run. Based on the inclusion of fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran tests. 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. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-18 3:44 ` Jacob Bachmeyer @ 2022-12-18 21:13 ` NightStrike 2022-12-19 4:29 ` Jacob Bachmeyer 0 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-18 21:13 UTC (permalink / raw) To: jcb62281; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> On 17.12.22 01:26, NightStrike wrote: > >> > >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >>> > >>>> On 16.12.22 03:20, NightStrike via Fortran wrote: > >>>> > >>>> > >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape > >>>>> sequences. We had fixed this long ago, but it seems to be back. Any > >>>>> idea what I should change in my configuration to have this not happen? > >>>>> > >>>> This should probably be fixed properly in some *.exp file, but you can > >>>> try setting the GCC_COLORS environment variable to an empty string > >>>> before running the test. > >>>> > >>> That didn't help. It looks like this is always escape 25h to start > >>> the output and 25l to end it, which I think is turning the cursor on > >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > >>> apparently fixed this previously by building wine with > >>> --without-curses > >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > >>> option to wine was removed. Is there a way to hack this on the Deja > >>> side to ignore the escapes? Or to tell it to run in a way that makes > >>> wine not emit them? > >>> > >> Truth is, I don't know. > >> > >> I have included the gcc mailing list in this reply, where more > >> knowledgeable people can be found :-) > >> > > > > Thanks. I'm including the dejagnu list, maybe someone there can help, too. > > > > For clarity, this is an example of what I see: > > > > Output was: > > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ > > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 > > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^M^M > > > > Should match: > > My_R1 : 78 56 34 12.* > > My_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > > > DejaGnu cannot routinely strip escape sequences because they could be > part of the intended output---or strictly forbidden in the intended > output. Further, I suspect that the comparison is being carried out in > the testsuite code rather than the framework, but the thread that > arrived on the DejaGnu list does not mention what test is failing or > what testsuite is being run. Based on the inclusion of > fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran > tests. Every GCC language testsuite has these failures, I just singled out Fortran because I was interested in it. > 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. 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. 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. 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-18 21:13 ` NightStrike @ 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-19 4:29 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: testsuite under wine 2022-12-19 4:29 ` Jacob Bachmeyer @ 2022-12-19 10:43 ` Torbjorn SVENSSON 2022-12-19 11:00 ` NightStrike 2022-12-19 11:13 ` NightStrike 2022-12-21 17:37 ` Jacek Caban 2 siblings, 1 reply; 44+ messages in thread From: Torbjorn SVENSSON @ 2022-12-19 10:43 UTC (permalink / raw) To: jcb62281, NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu Hi, > -----Original Message----- > From: dejagnu-bounces+torbjorn.svensson=st.com@gnu.org <dejagnu- > bounces+torbjorn.svensson=st.com@gnu.org> On Behalf Of Jacob Bachmeyer > Sent: den 19 december 2022 05:29 > To: NightStrike <nightstrike@gmail.com> > Cc: Thomas Koenig <tkoenig@netcologne.de>; fortran@gcc.gnu.org; gcc > mailing list <gcc@gcc.gnu.org>; dejagnu@gnu.org > Subject: Re: testsuite under wine > > 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. I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back. What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output. I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway. Kind regards, Torbjörn ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-19 10:43 ` Torbjorn SVENSSON @ 2022-12-19 11:00 ` NightStrike 0 siblings, 0 replies; 44+ messages in thread From: NightStrike @ 2022-12-19 11:00 UTC (permalink / raw) To: Torbjorn SVENSSON Cc: jcb62281, Thomas Koenig, fortran, gcc mailing list, dejagnu On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON <torbjorn.svensson@st.com> wrote: > I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back. > What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output. > > I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway. This is extremely helpful for when I start testing natively, thank you. I think in general the problem is the same, but Wine doesn't immediately have a comparable workaround. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON @ 2022-12-19 11:13 ` NightStrike 2022-12-20 3:51 ` Jacob Bachmeyer 2022-12-21 17:37 ` Jacek Caban 2 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-19 11:13 UTC (permalink / raw) To: jcb62281; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > 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. I think it's a paradigm difference. I'm just guessing here, but Wine runs in a terminal that doesn't know about TERM. It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable). In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...) [...snip for now, I'm working on getting reasonable output back to you, including an example of a case that fails, and how it responds to your suggestion. Stay tuned...] > > 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. Agreed, just trying to get by for now. > > 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. Here's one that tries to handle different line endings (most tests do not do this): gfortran.dg/parameter_array_dummy.f90 which uses: ! { dg-output " *1 aa(\n|\r\n|\r)" } ! { dg-output " *2 ab(\n|\r\n|\r)" } ! { dg-output " *3 aaab(\n|\r\n|\r)" } ! { dg-output " *4 abaa(\n|\r\n|\r)" } ! { dg-output " *5 ababab(\n|\r\n|\r)" } But this results in: FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test Output was: 1 aa^M^M 2 ab^M^M 3 aaab^M^M 4 abaa^M^M 5 ababab^M^M Should match: *1 aa( |^M |^M) *2 ab( |^M |^M) *3 aaab( |^M |^M) *4 abaa( |^M |^M) *5 ababab( |^M |^M) The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n. (Other examples fail differently, for instance there's a Rust test that outputs \r\r\n\n... but let's start with this one). ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-19 11:13 ` NightStrike @ 2022-12-20 3:51 ` Jacob Bachmeyer 0 siblings, 0 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-20 3:51 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu NightStrike wrote: > On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> 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. >> > > I think it's a paradigm difference. I'm just guessing here, but Wine > runs in a terminal that doesn't know about TERM. Terminals never know about TERM. TERM exists to inform programs what terminal type they are running with. X11 terminal emulators *set* TERM in the environment given to their child processes to identify themselves for this reason. > It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable). Yes, but Wine must emulate a console window with the terminal that it has, which is not necessarily a VT100-alike, therefore it should be checking the TERM variable at the minimum, and preferably using terminfo to adapt whatever escape sequences the terminal in use actually expects, or gracefully degrade when the terminal simply does not support the needed features. (Minor technical note: while cmd.exe is a console program, it does not actually provide the console; that is a different part of the NT system, but I am not certain exactly what. Wine is trying to emulate the Windows console, not cmd.exe.) > In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...) > Ah yes, Windows has some serious performance problems related to spawning processes. :-D I once cross-compiled GNU libc from a Windows (98SE) host while setting up my first GNU/Linux system. It took about three days and the machine needed a universal Windows fix-it (reboot) afterwards due to memory leaks resulting in swap thrashing that continued even after all application programs had been closed---just a desktop, disk light on almost solidly, mouse pointer lagging mouse movement visibly. Later, on the same hardware but using a Linux kernel, rebuilding glibc took the expected two hours. Also, the same hardware semi-regularly locked up solid (even the mouse pointer would not move) with Windows... and not even once with GNU/Linux/XFree86. [...snip extended rant...] > [...] >>> 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. >> > > Here's one that tries to handle different line endings (most tests do > not do this): > > gfortran.dg/parameter_array_dummy.f90 > > which uses: > ! { dg-output " *1 aa(\n|\r\n|\r)" } > ! { dg-output " *2 ab(\n|\r\n|\r)" } > ! { dg-output " *3 aaab(\n|\r\n|\r)" } > ! { dg-output " *4 abaa(\n|\r\n|\r)" } > ! { dg-output " *5 ababab(\n|\r\n|\r)" } > > But this results in: > > FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test > [...] > > The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n. > These are testsuite bugs. This detail also (finally) tells me that the framework /is/ involved here after all, so there are possibilities for enhancing lib/dg.exp to reduce these issues. One possibility could be to use "$" in dg-output patterns as an end-of-line marker, internally substituted with a known EOL pattern for the platform being tested. (Not yet implemented, and testsuites using it would not be able to run with older framework versions.) Another solution is to note that dg-output matching does *not* use Expect and is actually batch-oriented: the test program is run (and its output gathered) using ${tool}_load, and then the patterns are matched against that returned output. This means that the Expect caveats described in the manual for normal tests do not apply here, and a simple EOL subpattern is usable: "[\r\n]+" (using that subpattern with Expect *will* cause subtle timing-related bugs) > (Other examples fail differently, for instance there's a Rust test > that outputs \r\r\n\n... but let's start with this one). > I believe that dg-output could reliably match that with an "[\r\n]+" subpattern, too. :-) One last detail that might help you: ${tool}_load has a chance to apply regsub(n) to the output before returning it. If the testsuite should ignore escape sequences, and you can match them with a Tcl regexp, you could use a similar conditional as my previous suggestion to prune the output before dg.exp examines it. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON 2022-12-19 11:13 ` NightStrike @ 2022-12-21 17:37 ` Jacek Caban 2022-12-22 1:01 ` NightStrike 2022-12-22 4:16 ` Jacob Bachmeyer 2 siblings, 2 replies; 44+ messages in thread From: Jacek Caban @ 2022-12-21 17:37 UTC (permalink / raw) To: jcb62281, fortran, NightStrike; +Cc: Eric Pouech [-- Attachment #1: Type: text/plain, Size: 3264 bytes --] Hi all, I'm responsible for Wine changes that cause your problems. I'm also CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, see [1] if you're interested in the context. Recent Wine versions implement Windows pseudo-consoles, see [2] for a bit more details. It's generally Microsoft's semi-recent API that's intended to be more compatible with POSIX than what was present in previous versions of Windows. In theory, with that implemented, we could just plug tty fds that we get from Unix and have Unix consoles working using those Windows APIs. In practice, it's not quite as good as promised and we need some tweaks to make it work nicely. We could improve those tweaks, but there are architectural limitations that will come to play sooner or later. > 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. I think that it would not be enough. The way Windows consoles work is that we manage complete internal screen buffer and emit output that synchronizes the buffer with Unix terminal inside conhost.exe process. It means that its output heavily processed and may be very different from what application writes to its console handle. While escape codes discussed in this thread are the most prominent difference (and that part could, in theory, be improved on our side), there are more differences. For example, if application writes "\rA\rB\rC", conhost will process it, update its internal buffer which changes just one character and cursor position, and emit sequence to update it in Unix terminal, which could be just "\rC" (or even "C" if cursor was already at the beginning of the line). Another example would be long lines: conhost will emit additional EOLs instead of depending on embedder to wrap the line. I'm not really familiar with DejaGnu, but if you want to match application output, that's probably not what you're looking for. The reason the previous workaround of compiling Wine without ncurses worked is that if made Wine treat tty stdin/stdout in a way very similar to regular pipes, so no extra processing was performed. This was more of a side effect than a design choice. It should be possible to provide some way to achieve that with the new Wine architecture. I'm attaching an example of Wine patch that would allow it. With that patch, you may disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d environment variable) and achieve something similar to previous workaround. Long term, I think that it would be best to get rid of console behaviour expectations by using Windows build of DejaGnu. My understanding is that it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on Wine on Linux. This would make all similar mismatches in expectations non-existent. Cygwin is tricky to run on Wine, there are a few known problems like [3], but we're getting there. Jacek [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html [2] https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ [3] https://bugs.winehq.org/show_bug.cgi?id=47808 [-- Attachment #2: console.diff --] [-- Type: text/x-patch, Size: 2400 bytes --] diff --git a/dlls/kernelbase/console.c b/dlls/kernelbase/console.c index 7cd87f53b3c..61569fda9a6 100644 --- a/dlls/kernelbase/console.c +++ b/dlls/kernelbase/console.c @@ -2307,33 +2307,45 @@ void init_console( void ) COORD size; if (is_tty_handle( params->hStdInput )) - { tty_in = params->hStdInput; - params->hStdInput = NULL; - } if (is_tty_handle( params->hStdOutput )) - { tty_out = params->hStdOutput; - params->hStdOutput = NULL; - } - if (is_tty_handle( params->hStdError )) - { - if (tty_out) CloseHandle( params->hStdError ); - else tty_out = params->hStdError; - params->hStdError = NULL; - } + else if (is_tty_handle( params->hStdError )) + tty_out = params->hStdError; size.X = params->dwXCountChars; size.Y = params->dwYCountChars; TRACE( "creating unix console (size %u %u)\n", size.X, size.Y ); params->ConsoleHandle = create_pseudo_console( size, tty_in, tty_out, NULL, 0, &process ); - CloseHandle( process ); - CloseHandle( tty_in ); - CloseHandle( tty_out ); - - if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle )) + if (params->ConsoleHandle) + { + CloseHandle( process ); + + if (is_tty_handle( params->hStdInput )) + { + CloseHandle( params->hStdInput ); + params->hStdInput = NULL; + } + if (is_tty_handle( params->hStdOutput )) + { + CloseHandle( params->hStdOutput ); + params->hStdOutput = NULL; + } + if (is_tty_handle( params->hStdError )) + { + CloseHandle( params->hStdError ); + params->hStdError = NULL; + } + + if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle )) + { + init_console_std_handles( FALSE ); + } + } + else { - init_console_std_handles( FALSE ); + WARN( "Failed to create console process\n" ); + params->ConsoleHandle = CONSOLE_HANDLE_SHELL_NO_WINDOW; } } else if (params->ConsoleHandle == CONSOLE_HANDLE_ALLOC || ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-21 17:37 ` Jacek Caban @ 2022-12-22 1:01 ` NightStrike 2022-12-22 4:37 ` Jacob Bachmeyer 2022-12-22 4:16 ` Jacob Bachmeyer 1 sibling, 1 reply; 44+ messages in thread From: NightStrike @ 2022-12-22 1:01 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, fortran, Eric Pouech, gcc, dejagnu On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <jacek@codeweavers.com> wrote: > > Hi all, > > > I'm responsible for Wine changes that cause your problems. I'm also > CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, > see [1] if you're interested in the context. > > > Recent Wine versions implement Windows pseudo-consoles, see [2] for a > bit more details. It's generally Microsoft's semi-recent API that's > intended to be more compatible with POSIX than what was present in > previous versions of Windows. In theory, with that implemented, we could > just plug tty fds that we get from Unix and have Unix consoles working > using those Windows APIs. In practice, it's not quite as good as > promised and we need some tweaks to make it work nicely. We could > improve those tweaks, but there are architectural limitations that will > come to play sooner or later. > > > > 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. > > > I think that it would not be enough. The way Windows consoles work is > that we manage complete internal screen buffer and emit output that > synchronizes the buffer with Unix terminal inside conhost.exe process. > It means that its output heavily processed and may be very different > from what application writes to its console handle. While escape codes > discussed in this thread are the most prominent difference (and that > part could, in theory, be improved on our side), there are more > differences. For example, if application writes "\rA\rB\rC", conhost > will process it, update its internal buffer which changes just one > character and cursor position, and emit sequence to update it in Unix > terminal, which could be just "\rC" (or even "C" if cursor was already > at the beginning of the line). Another example would be long lines: > conhost will emit additional EOLs instead of depending on embedder to > wrap the line. I'm not really familiar with DejaGnu, but if you want to > match application output, that's probably not what you're looking for. > > > The reason the previous workaround of compiling Wine without ncurses > worked is that if made Wine treat tty stdin/stdout in a way very similar > to regular pipes, so no extra processing was performed. This was more of > a side effect than a design choice. It should be possible to provide > some way to achieve that with the new Wine architecture. I'm attaching > an example of Wine patch that would allow it. With that patch, you may > disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d > environment variable) and achieve something similar to previous workaround. > > > Long term, I think that it would be best to get rid of console behaviour > expectations by using Windows build of DejaGnu. My understanding is that > it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on > Wine on Linux. This would make all similar mismatches in expectations > non-existent. Cygwin is tricky to run on Wine, there are a few known > problems like [3], but we're getting there. > > > Jacek > > > [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html > > [2] > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > > [3] https://bugs.winehq.org/show_bug.cgi?id=47808 First, a big giant thank you for this patch. I confirmed that I can use this to replace the "return immediately from init_console" hack, and it applies cleanly to 7.20. Second, the problems with extra \r's still remain, but I think we've generally come to think that that part isn't Wine and is instead either the testsuite or deja. So I'll keep those replies to Jacob's previous message. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-22 1:01 ` NightStrike @ 2022-12-22 4:37 ` Jacob Bachmeyer 2022-12-23 10:36 ` NightStrike 0 siblings, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-22 4:37 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > [...] > Second, the problems with extra \r's still remain, but I think we've > generally come to think that that part isn't Wine and is instead > either the testsuite or deja. So I'll keep those replies to Jacob's > previous message. > Most likely, it is a combination of the MinGW libc (which emits "\r\n" for end-of-line in accordance with Windows convention) and the kernel terminal driver (which passes "\r" and translates "\n" to "\r\n" in accordance with POSIX convention). Wine, short of trying to translate "\r\n" back to "\n" in accordance with POSIX conventions (and likely making an even bigger mess---does Wine know if a handle is supposed to be text or binary?) cannot really fix this, so the testsuite needs to handle non-POSIX-standard line endings. (The Rust tests probably have an outright bug if the newlines are being duplicated.) -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-22 4:37 ` Jacob Bachmeyer @ 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 0 siblings, 2 replies; 44+ messages in thread From: NightStrike @ 2022-12-23 10:36 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > [...] > > Second, the problems with extra \r's still remain, but I think we've > > generally come to think that that part isn't Wine and is instead > > either the testsuite or deja. So I'll keep those replies to Jacob's > > previous message. > > > > Most likely, it is a combination of the MinGW libc (which emits "\r\n" > for end-of-line in accordance with Windows convention) and the kernel > terminal driver (which passes "\r" and translates "\n" to "\r\n" in > accordance with POSIX convention). Wine, short of trying to translate > "\r\n" back to "\n" in accordance with POSIX conventions (and likely > making an even bigger mess---does Wine know if a handle is supposed to > be text or binary?) cannot really fix this, so the testsuite needs to > handle non-POSIX-standard line endings. (The Rust tests probably have > an outright bug if the newlines are being duplicated.) You may be onto something here. I ran wine under script as `script -c "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r prepended to the \r\n. I was making the mistake previously of running wine manually and capturing it to a file as `wine64 ./a.exe > out`, which as several have pointed out in this thread, that would disable the quirk, so of course it didn't reveal any problems. I'm behind, but I'll catch up to you guys eventually :) So at least we know for sure that this particular instance of extra characters is coming from Wine. Maybe Wine can be smart enough to only translate \n into \r\n instead of translating \r\n into \r\r\n. Jacek / Eric, comments here? I'm happy to try another patch, the first one was great. Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could be the rust test, could be the rust frontend, could be another weird Wine interaction. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-23 10:36 ` NightStrike @ 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 1 sibling, 0 replies; 44+ messages in thread From: Eric Pouech @ 2022-12-23 12:43 UTC (permalink / raw) To: NightStrike, jcb62281; +Cc: Jacek Caban, fortran, gcc, dejagnu Le 23/12/2022 à 11:36, NightStrike a écrit : > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >> NightStrike wrote: >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > actually, it depends on how the file has been opened by the application. if it's done in binary mode, no \n => \r\n translation takes place but it the file is opened in text mode, wine just does what the application requires, which is \n => \r\n translation (and by default, stdout and stderr are opened in text mode) IMO, you should not expect more from Wine. Wine's goal is to run windows application on Unix ; it's not to run windows applications on Unix and requiring that they behave as they had been written for Linux semantics anyway, we (wine) have to go back to blackboard to figure out a solution for disabling nicely conhost in the meantime, you could use (without any patch to wine), some wrapper (bash) script like: #!/bin/bash # assumes wine is in $PATH case "$1" in --unix-raw) shift; cat | wine $* 1> >(tee /dev/null) 2> >(tee /dev/null >&2);; --unix-lf) shift; cat | wine $* 1> >(tee /dev/null | sed 's/\r$//' ) 2> >(tee /dev/null | sed 's/\r$//' >&2);; *) wine $*;; esac using --unix-raw will just disable conhost (hence shall remove most of the ansi sequences reported) using --unix-lf will also disable conhost and replace \r\n with \n this shall put wine in the behavior as you expect, and still allow using proper redirection and piping on the shell script if needed (without alterning wine's behavior) (this could be further improved by not adding a pipe for fd:s that are not tty, or adapted to be triggered when, say, TERM=dumb) HTH ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech @ 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 1 sibling, 2 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-24 4:00 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) >> > > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > So close, and yet so far... script(1) /also/ uses a pty, so it is getting the same translations as Expect and therefore DejaGnu. > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > I doubt that Wine is doing that translation. MinGW libc produces output conformant to Windows conventions, so printf("\n") on a text handle emits "\r\n", which Wine passes along. POSIX convention is that "\n" is translated to "\r\n" in the kernel terminal driver upon output, so the kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be prepared to discard excess carriage returns. The first CR came from MinGW libc; the second CR came from the kernel terminal driver; the LF was ultimately passed through. > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could > be the rust test, could be the rust frontend, could be another weird > Wine interaction. > That is probably either a Rust bug or the intended behavior. Does the test produce "\n\n" or "\r\n\n" when run natively? (Note that the terminal driver could reasonably optimize: once one CR has been produced, any number of LF may follow: the cursor is assumed to remain at the left edge. It is possible that the kernel terminal driver could even strip the second CR in "\r\n\r\n" since its only effect on an actual serial terminal would be wasting transmission time.) -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-24 4:00 ` Jacob Bachmeyer @ 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 1 sibling, 0 replies; 44+ messages in thread From: Mark Wielaard @ 2022-12-24 11:05 UTC (permalink / raw) To: jcb62281; +Cc: NightStrike, Jacek Caban, fortran, Eric Pouech, gcc, dejagnu Hi, On Fri, Dec 23, 2022 at 10:00:36PM -0600, Jacob Bachmeyer via Gcc wrote: > NightStrike wrote: > > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could > > be the rust test, could be the rust frontend, could be another weird > > Wine interaction. > > That is probably either a Rust bug or the intended behavior. Note that in rust a string tokens or doc comments with an "Isolated CR" (a \r not immediately followed by an \n) is an error and the testsuite contains a couple of tests to make sure the compiler detects that. Which might cause even more confusion. Cheers, Mark ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard @ 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:41 ` Jerry D 1 sibling, 2 replies; 44+ messages in thread From: NightStrike @ 2023-01-05 2:50 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > NightStrike wrote: > > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: > >> > >>> [...] > >>> Second, the problems with extra \r's still remain, but I think we've > >>> generally come to think that that part isn't Wine and is instead > >>> either the testsuite or deja. So I'll keep those replies to Jacob's > >>> previous message. > >>> > >>> > >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" > >> for end-of-line in accordance with Windows convention) and the kernel > >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in > >> accordance with POSIX convention). Wine, short of trying to translate > >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely > >> making an even bigger mess---does Wine know if a handle is supposed to > >> be text or binary?) cannot really fix this, so the testsuite needs to > >> handle non-POSIX-standard line endings. (The Rust tests probably have > >> an outright bug if the newlines are being duplicated.) > >> > > > > You may be onto something here. I ran wine under script as `script -c > > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > > prepended to the \r\n. I was making the mistake previously of running > > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > > which as several have pointed out in this thread, that would disable > > the quirk, so of course it didn't reveal any problems. I'm behind, > > but I'll catch up to you guys eventually :) > > > > So close, and yet so far... script(1) /also/ uses a pty, so it is > getting the same translations as Expect and therefore DejaGnu. > > > So at least we know for sure that this particular instance of extra > > characters is coming from Wine. Maybe Wine can be smart enough to > > only translate \n into \r\n instead of translating \r\n into \r\r\n. > > Jacek / Eric, comments here? I'm happy to try another patch, the > > first one was great. > > > > I doubt that Wine is doing that translation. MinGW libc produces output > conformant to Windows conventions, so printf("\n") on a text handle > emits "\r\n", which Wine passes along. POSIX convention is that "\n" is > translated to "\r\n" in the kernel terminal driver upon output, so the > kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding > "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be > prepared to discard excess carriage returns. The first CR came from > MinGW libc; the second CR came from the kernel terminal driver; the LF > was ultimately passed through. Jacek and I have been digging into this on IRC, and he's been very helpful in trying to get further, but we're still stuck. We tried to be more introspective, inserting strace both as "strace script wine" and as "script strace wine". We tried running just "wine a.exe" without any extra glue, and logging the raw SSH packets from putty. After many iterations on these and other tests, Jacek finally had the idea to try removing Windows entirely from the equation, and we ran with a purely unix program / compiler combination: #include <unistd.h> int main() { write(1, "test\r\n", 6); return 0; } (and also as "test\n", 5) In both versions, the following was observed: case 1) ./a.out | xxd case 2) script -c ./a.out out; xxd out case 3) enable putting logging, ./a.out In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). So, is it possible after all of this back and forth regarding mingw, wine, and others, that it's down to the write() system call that's inserting extra \r's? Is this expected? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-05 2:50 ` NightStrike @ 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 2023-01-06 3:41 ` Jerry D 1 sibling, 2 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2023-01-06 3:33 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >>> >>>> [...] >>> So at least we know for sure that this particular instance of extra >>> characters is coming from Wine. Maybe Wine can be smart enough to >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>> Jacek / Eric, comments here? I'm happy to try another patch, the >>> first one was great. >>> >>> >> I doubt that Wine is doing that translation. MinGW libc produces output >> conformant to Windows conventions, so printf("\n") on a text handle >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >> translated to "\r\n" in the kernel terminal driver upon output, so the >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >> prepared to discard excess carriage returns. The first CR came from >> MinGW libc; the second CR came from the kernel terminal driver; the LF >> was ultimately passed through. >> > > Jacek and I have been digging into this on IRC, and he's been very > helpful in trying to get further, but we're still stuck. We tried to > be more introspective, inserting strace both as "strace script wine" > and as "script strace wine". We tried running just "wine a.exe" > without any extra glue, and logging the raw SSH packets from putty. > After many iterations on these and other tests, Jacek finally had the > idea to try removing Windows entirely from the equation, and we ran > with a purely unix program / compiler combination: > > #include <unistd.h> > > int main() > { > write(1, "test\r\n", 6); > return 0; > } > > (and also as "test\n", 5) > > In both versions, the following was observed: > > case 1) ./a.out | xxd > case 2) script -c ./a.out out; xxd out > case 3) enable putting logging, ./a.out > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > So, is it possible after all of this back and forth regarding mingw, > wine, and others, that it's down to the write() system call that's > inserting extra \r's? Is this expected? > "This is why DejaGnu testsuites must be prepared to discard excess carriage returns." The write(2) system call inserts nothing and simply hands off the buffer to the relevant part of the kernel I/O subsystem. (The kernel in POSIX is *not* a monolithic black box.) When stdout for your test program is a pty slave, that relevant part is the kernel terminal driver. The kernel terminal driver is converting "\n" to "\r\n" upon output to the associated port, since hardware terminals typically *do* require CRLF. The associated port in this case is virtual and part of the kernel pty subsystem, which presents octets written to that port to its associated pty master device. The user-visible pty slave device acts just like a serial terminal, including all translations normally done for handling serial terminals. A pty is conceptually a null-modem cable connected between two infinitely-fast serial ports on the same machine, although the slave will still report an actual baud rate if queried. (Run "stty" with no arguments under script(1), an ssh session, or an X11 terminal emulator to see what a pty slave looks like on your machine.) In your case 1, the pty subsystem is not used and output is collected over a pipe. Using "./a.out > out; xxd out" would produce the same results. In cases 2 and 3, there is a pty involved, either set up by script(1) or by sshd (assuming you meant "enable putty logging" in case 3) that performs the standard terminal translations. In all cases, strace(1) will show the exact string written to the pty slave device, which will not include any extra CRs because *those* *are* *inserted* *by* *the* *kernel* *terminal* *driver* as the data is transferred to the pty master device's read queue. This insertion of carriage returns is expected and standardized behavior in POSIX and is the reason Unix could use bare LF as end-of-line even though hardware terminals always needed CRLF. CP/M (and therefore MS-DOS which began its existence as a cheap CP/M knockoff) did not have this translation layer and instead dumped the complexity of a two-octet end-of-line sequence on user programs, leading to much confusion even today. This is not a Wine issue, although the terminal escape sequences in your original issue *were* from Wine. Note that the number of excess carriage returns that a DejaGnu testsuite must be prepared to discard is unspecified because running tests on remote targets may result in *any* *number* of CRs preceding each LF by the time the results reach the test driver machine in more complex testing lab environments. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-06 3:33 ` Jacob Bachmeyer @ 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 1 sibling, 0 replies; 44+ messages in thread From: Jerry D @ 2023-01-06 3:44 UTC (permalink / raw) To: jcb62281, NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote: > NightStrike wrote: >> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> >> wrote: >>> NightStrike wrote: >>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer >>>> <jcb62281@gmail.com> wrote: >>>>> [...] >>>> So at least we know for sure that this particular instance of extra >>>> characters is coming from Wine. Maybe Wine can be smart enough to >>>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>>> Jacek / Eric, comments here? I'm happy to try another patch, the >>>> first one was great. >>>> >>> I doubt that Wine is doing that translation. MinGW libc produces output >>> conformant to Windows conventions, so printf("\n") on a text handle >>> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >>> translated to "\r\n" in the kernel terminal driver upon output, so the >>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >>> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >>> prepared to discard excess carriage returns. The first CR came from >>> MinGW libc; the second CR came from the kernel terminal driver; the LF >>> was ultimately passed through. >> >> Jacek and I have been digging into this on IRC, and he's been very >> helpful in trying to get further, but we're still stuck. We tried to >> be more introspective, inserting strace both as "strace script wine" >> and as "script strace wine". We tried running just "wine a.exe" >> without any extra glue, and logging the raw SSH packets from putty. >> After many iterations on these and other tests, Jacek finally had the >> idea to try removing Windows entirely from the equation, and we ran >> with a purely unix program / compiler combination: >> >> #include <unistd.h> >> >> int main() >> { >> write(1, "test\r\n", 6); >> return 0; >> } >> >> (and also as "test\n", 5) >> >> In both versions, the following was observed: >> >> case 1) ./a.out | xxd >> case 2) script -c ./a.out out; xxd out >> case 3) enable putting logging, ./a.out >> >> In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an >> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). >> >> So, is it possible after all of this back and forth regarding mingw, >> wine, and others, that it's down to the write() system call that's >> inserting extra \r's? Is this expected? > > "This is why DejaGnu testsuites must be prepared to discard excess > carriage returns." > > The write(2) system call inserts nothing and simply hands off the buffer > to the relevant part of the kernel I/O subsystem. (The kernel in POSIX > is *not* a monolithic black box.) When stdout for your test program is > a pty slave, that relevant part is the kernel terminal driver. The > kernel terminal driver is converting "\n" to "\r\n" upon output to the > associated port, since hardware terminals typically *do* require CRLF. > The associated port in this case is virtual and part of the kernel pty > subsystem, which presents octets written to that port to its associated > pty master device. The user-visible pty slave device acts just like a > serial terminal, including all translations normally done for handling > serial terminals. > > A pty is conceptually a null-modem cable connected between two > infinitely-fast serial ports on the same machine, although the slave > will still report an actual baud rate if queried. (Run "stty" with no > arguments under script(1), an ssh session, or an X11 terminal emulator > to see what a pty slave looks like on your machine.) > > In your case 1, the pty subsystem is not used and output is collected > over a pipe. Using "./a.out > out; xxd out" would produce the same > results. In cases 2 and 3, there is a pty involved, either set up by > script(1) or by sshd (assuming you meant "enable putty logging" in case > 3) that performs the standard terminal translations. In all cases, > strace(1) will show the exact string written to the pty slave device, > which will not include any extra CRs because *those* *are* *inserted* > *by* *the* *kernel* *terminal* *driver* as the data is transferred to > the pty master device's read queue. > > This insertion of carriage returns is expected and standardized behavior > in POSIX and is the reason Unix could use bare LF as end-of-line even > though hardware terminals always needed CRLF. CP/M (and therefore > MS-DOS which began its existence as a cheap CP/M knockoff) did not have > this translation layer and instead dumped the complexity of a two-octet > end-of-line sequence on user programs, leading to much confusion even > today. This is not a Wine issue, although the terminal escape sequences > in your original issue *were* from Wine. Note that the number of excess > carriage returns that a DejaGnu testsuite must be prepared to discard is > unspecified because running tests on remote targets may result in *any* > *number* of CRs preceding each LF by the time the results reach the test > driver machine in more complex testing lab environments. > > > -- Jacob Agree ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D @ 2023-01-08 7:12 ` NightStrike 2023-01-11 2:30 ` Jacob Bachmeyer 1 sibling, 1 reply; 44+ messages in thread From: NightStrike @ 2023-01-08 7:12 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > > >> NightStrike wrote: > >> > >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >>> > >>>> [...] > >>> So at least we know for sure that this particular instance of extra > >>> characters is coming from Wine. Maybe Wine can be smart enough to > >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. > >>> Jacek / Eric, comments here? I'm happy to try another patch, the > >>> first one was great. > >>> > >>> > >> I doubt that Wine is doing that translation. MinGW libc produces output > >> conformant to Windows conventions, so printf("\n") on a text handle > >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is > >> translated to "\r\n" in the kernel terminal driver upon output, so the > >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding > >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be > >> prepared to discard excess carriage returns. The first CR came from > >> MinGW libc; the second CR came from the kernel terminal driver; the LF > >> was ultimately passed through. > >> > > > > Jacek and I have been digging into this on IRC, and he's been very > > helpful in trying to get further, but we're still stuck. We tried to > > be more introspective, inserting strace both as "strace script wine" > > and as "script strace wine". We tried running just "wine a.exe" > > without any extra glue, and logging the raw SSH packets from putty. > > After many iterations on these and other tests, Jacek finally had the > > idea to try removing Windows entirely from the equation, and we ran > > with a purely unix program / compiler combination: > > > > #include <unistd.h> > > > > int main() > > { > > write(1, "test\r\n", 6); > > return 0; > > } > > > > (and also as "test\n", 5) > > > > In both versions, the following was observed: > > > > case 1) ./a.out | xxd > > case 2) script -c ./a.out out; xxd out > > case 3) enable putting logging, ./a.out > > > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > > > So, is it possible after all of this back and forth regarding mingw, > > wine, and others, that it's down to the write() system call that's > > inserting extra \r's? Is this expected? > > > > "This is why DejaGnu testsuites must be prepared to discard excess > carriage returns." > > The write(2) system call inserts nothing and simply hands off the buffer > to the relevant part of the kernel I/O subsystem. (The kernel in POSIX > is *not* a monolithic black box.) When stdout for your test program is > a pty slave, that relevant part is the kernel terminal driver. The > kernel terminal driver is converting "\n" to "\r\n" upon output to the > associated port, since hardware terminals typically *do* require CRLF. > The associated port in this case is virtual and part of the kernel pty > subsystem, which presents octets written to that port to its associated > pty master device. The user-visible pty slave device acts just like a > serial terminal, including all translations normally done for handling > serial terminals. > > A pty is conceptually a null-modem cable connected between two > infinitely-fast serial ports on the same machine, although the slave > will still report an actual baud rate if queried. (Run "stty" with no > arguments under script(1), an ssh session, or an X11 terminal emulator > to see what a pty slave looks like on your machine.) > > In your case 1, the pty subsystem is not used and output is collected > over a pipe. Using "./a.out > out; xxd out" would produce the same > results. In cases 2 and 3, there is a pty involved, either set up by > script(1) or by sshd (assuming you meant "enable putty logging" in case > 3) that performs the standard terminal translations. In all cases, > strace(1) will show the exact string written to the pty slave device, > which will not include any extra CRs because *those* *are* *inserted* > *by* *the* *kernel* *terminal* *driver* as the data is transferred to > the pty master device's read queue. > > This insertion of carriage returns is expected and standardized behavior > in POSIX and is the reason Unix could use bare LF as end-of-line even > though hardware terminals always needed CRLF. CP/M (and therefore > MS-DOS which began its existence as a cheap CP/M knockoff) did not have > this translation layer and instead dumped the complexity of a two-octet > end-of-line sequence on user programs, leading to much confusion even > today. This is not a Wine issue, although the terminal escape sequences > in your original issue *were* from Wine. Note that the number of excess > carriage returns that a DejaGnu testsuite must be prepared to discard is > unspecified because running tests on remote targets may result in *any* > *number* of CRs preceding each LF by the time the results reach the test > driver machine in more complex testing lab environments. First, I just want to thank you for your patience. You are putting a lot of effort into these replies, and it is appreciated. I did another little test to try to better understand your point. I ran a linux native testsuite under a simulator that just sets SIM to " ". This resulted in extra ^M's also, although many tests pass because they're already looking for \r\n to accommodate windows. So I think I've come around to grasp what you've been heroically re-explaining... So if we have to modify every test in the entire testsuite to check for zero or more \r's followed by zero or more \n's, would it be better to add a dg-output-line proc that does this automatically everywhere? I feel like changing every output pattern test won't be too maintainable. You had mentioned previously modifying ${tool}_load to filter out extra \r's, but I couldn't see where or how to do that. For completeness, setting a random selection of tests to look for \r*\n? worked (this would cover even deprecated systems that only use CR as well as flagging the weird rust case of \r\r\n\n as bad). ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-08 7:12 ` NightStrike @ 2023-01-11 2:30 ` Jacob Bachmeyer 2023-01-11 9:33 ` NightStrike 0 siblings, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2023-01-11 2:30 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > [...] > I did another little test to try to better understand your point. I > ran a linux native testsuite under a simulator that just sets SIM to " > ". This resulted in extra ^M's also, although many tests pass because > they're already looking for \r\n to accommodate windows. So I think > I've come around to grasp what you've been heroically re-explaining... > > So if we have to modify every test in the entire testsuite to check > for zero or more \r's followed by zero or more \n's, would it be > better to add a dg-output-line proc that does this automatically > everywhere? Two problems: first, you need zero-or-more \r and *one*-or-more \n. Second, dg-output is not defined as an anchored match, and therefore cannot do this automatically. > I feel like changing every output pattern test won't be > too maintainable. You had mentioned previously modifying ${tool}_load > to filter out extra \r's, but I couldn't see where or how to do that. > > For completeness, setting a random selection of tests to look for > \r*\n? worked (this would cover even deprecated systems that only use > CR as well as flagging the weird rust case of \r\r\n\n as bad). Do not worry about classic Mac OS---running DejaGnu on that platform is not possible, nor is it possible to run test programs remotely on that platform. Classic Mac OS is a pure-GUI system with no command interface whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl exec(n) command. Due to limitations of the platform, porting Expect to classic Mac OS is simply not possible. Any compatibility layer would be reasonably expected to translate CR<->LF, if, for example, someone wrote a telnet server (and associated POSIX-alike environment) for Mac OS. The later Mac OS X is a quasi-POSIX mostly compatible with the GNU system that uses POSIX line endings. DejaGnu should run normally there. Are there other systems that used bare CR as end-of-line? If not, the correct pattern is therefore {\r*\n} (here written using braces as quotes around the pattern). -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-11 2:30 ` Jacob Bachmeyer @ 2023-01-11 9:33 ` NightStrike 2023-01-12 4:11 ` Jacob Bachmeyer 0 siblings, 1 reply; 44+ messages in thread From: NightStrike @ 2023-01-11 9:33 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > [...] > > I did another little test to try to better understand your point. I > > ran a linux native testsuite under a simulator that just sets SIM to " > > ". This resulted in extra ^M's also, although many tests pass because > > they're already looking for \r\n to accommodate windows. So I think > > I've come around to grasp what you've been heroically re-explaining... > > > > So if we have to modify every test in the entire testsuite to check > > for zero or more \r's followed by zero or more \n's, would it be > > better to add a dg-output-line proc that does this automatically > > everywhere? > > Two problems: first, you need zero-or-more \r and *one*-or-more \n. > Second, dg-output is not defined as an anchored match, and therefore > cannot do this automatically. "or more" \n is valid? That would make the rust bug of \r\r\n\n pass when I assume it shouldn't. > > I feel like changing every output pattern test won't be > > too maintainable. You had mentioned previously modifying ${tool}_load > > to filter out extra \r's, but I couldn't see where or how to do that. > > > > For completeness, setting a random selection of tests to look for > > \r*\n? worked (this would cover even deprecated systems that only use > > CR as well as flagging the weird rust case of \r\r\n\n as bad). > > Do not worry about classic Mac OS---running DejaGnu on that platform is > not possible, nor is it possible to run test programs remotely on that > platform. Classic Mac OS is a pure-GUI system with no command interface > whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl > exec(n) command. Due to limitations of the platform, porting Expect to > classic Mac OS is simply not possible. Any compatibility layer would be > reasonably expected to translate CR<->LF, if, for example, someone wrote > a telnet server (and associated POSIX-alike environment) for Mac OS. > > The later Mac OS X is a quasi-POSIX mostly compatible with the GNU > system that uses POSIX line endings. DejaGnu should run normally there. > > Are there other systems that used bare CR as end-of-line? If not, the > correct pattern is therefore {\r*\n} (here written using braces as > quotes around the pattern). Maybe none that matter. From https://en.wikipedia.org/wiki/Newline#Representation: Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80, Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9 The article also goes on to mention that OpenVMS and RSX-11 can be configured to use CR. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-11 9:33 ` NightStrike @ 2023-01-12 4:11 ` Jacob Bachmeyer 0 siblings, 0 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2023-01-12 4:11 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> [...] >>> I did another little test to try to better understand your point. I >>> ran a linux native testsuite under a simulator that just sets SIM to " >>> ". This resulted in extra ^M's also, although many tests pass because >>> they're already looking for \r\n to accommodate windows. So I think >>> I've come around to grasp what you've been heroically re-explaining... >>> >>> So if we have to modify every test in the entire testsuite to check >>> for zero or more \r's followed by zero or more \n's, would it be >>> better to add a dg-output-line proc that does this automatically >>> everywhere? >>> >> Two problems: first, you need zero-or-more \r and *one*-or-more \n. >> Second, dg-output is not defined as an anchored match, and therefore >> cannot do this automatically. >> > > "or more" \n is valid? Only if you are ignoring blank lines. Note that you had earlier said zero-or-more \r and zero-or-more \n, which would be a pattern that can match with zero length. > That would make the rust bug of \r\r\n\n pass > when I assume it shouldn't. > The pattern that I suggested as correct is zero-or-more \r followed by exactly one \n. If you are ignoring blank lines in buffered text, but /not/ in live Expect, you can use {[\r\n]+} (any non-empty sequence of \r and \n) but this will /not/ work with live Expect, because it can match a prefix of the intended text. >>> I feel like changing every output pattern test won't be >>> too maintainable. You had mentioned previously modifying ${tool}_load >>> to filter out extra \r's, but I couldn't see where or how to do that. >>> >>> For completeness, setting a random selection of tests to look for >>> \r*\n? worked (this would cover even deprecated systems that only use >>> CR as well as flagging the weird rust case of \r\r\n\n as bad). >>> >> Do not worry about classic Mac OS---running DejaGnu on that platform is >> not possible, nor is it possible to run test programs remotely on that >> platform. Classic Mac OS is a pure-GUI system with no command interface >> whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl >> exec(n) command. Due to limitations of the platform, porting Expect to >> classic Mac OS is simply not possible. Any compatibility layer would be >> reasonably expected to translate CR<->LF, if, for example, someone wrote >> a telnet server (and associated POSIX-alike environment) for Mac OS. >> >> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU >> system that uses POSIX line endings. DejaGnu should run normally there. >> >> Are there other systems that used bare CR as end-of-line? If not, the >> correct pattern is therefore {\r*\n} (here written using braces as >> quotes around the pattern). >> > > Maybe none that matter. From > https://en.wikipedia.org/wiki/Newline#Representation: > > Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80, > Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9 > DejaGnu is not going to run on any of those, and remote testing with any of those as targets gets ... "interesting" ... very quickly. Oberon, similarly to classic MacOS simply does not have a command line, although it /does/ have enough infrastructure that implementing some kind of line-oriented command interface could be feasible and some Oberon versions do have network capability. Nonetheless, the entire Oberon system is written in its own language, so a testsuite for an Oberon target would be expected to be specially written accordingly. I already mentioned classic MacOS. Lisp Machines evaluate similarly to Oberon, using their own language for all software (in this case, Lisp) with the additional element of being highly unlikely to be found outside of a computer museum, having never been common. OS-9 is interesting, but is an oddball nonfree system with niche uses. Nonetheless, it does have a shell, so it fits in with the others mentioned below. The rest are various 8-bit systems, where some level of remote testing might be possible over a serial line, but see stty(1) and the icrnl and inlcr options for that case (the POSIX terminal driver can translate incoming CR to LF and vice versa). > The article also goes on to mention that OpenVMS and RSX-11 can be > configured to use CR. > Those systems actually store each line as a separate record; the /same/ file can be read with LF or CRLF by simply asking, if I read that article correctly. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer @ 2023-01-06 3:41 ` Jerry D 1 sibling, 0 replies; 44+ messages in thread From: Jerry D @ 2023-01-06 3:41 UTC (permalink / raw) To: NightStrike, jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On 1/4/23 6:50 PM, NightStrike via Fortran wrote: > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >> NightStrike wrote: >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >>>> NightStrike wrote: >>>> >>>>> [...] >>>>> Second, the problems with extra \r's still remain, but I think we've >>>>> generally come to think that that part isn't Wine and is instead >>>>> either the testsuite or deja. So I'll keep those replies to Jacob's >>>>> previous message. >>>>> >>>>> >>>> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >>>> for end-of-line in accordance with Windows convention) and the kernel >>>> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >>>> accordance with POSIX convention). Wine, short of trying to translate >>>> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >>>> making an even bigger mess---does Wine know if a handle is supposed to >>>> be text or binary?) cannot really fix this, so the testsuite needs to >>>> handle non-POSIX-standard line endings. (The Rust tests probably have >>>> an outright bug if the newlines are being duplicated.) >>>> >>> >>> You may be onto something here. I ran wine under script as `script -c >>> "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r >>> prepended to the \r\n. I was making the mistake previously of running >>> wine manually and capturing it to a file as `wine64 ./a.exe > out`, >>> which as several have pointed out in this thread, that would disable >>> the quirk, so of course it didn't reveal any problems. I'm behind, >>> but I'll catch up to you guys eventually :) >>> >> >> So close, and yet so far... script(1) /also/ uses a pty, so it is >> getting the same translations as Expect and therefore DejaGnu. >> >>> So at least we know for sure that this particular instance of extra >>> characters is coming from Wine. Maybe Wine can be smart enough to >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>> Jacek / Eric, comments here? I'm happy to try another patch, the >>> first one was great. >>> >> >> I doubt that Wine is doing that translation. MinGW libc produces output >> conformant to Windows conventions, so printf("\n") on a text handle >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >> translated to "\r\n" in the kernel terminal driver upon output, so the >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >> prepared to discard excess carriage returns. The first CR came from >> MinGW libc; the second CR came from the kernel terminal driver; the LF >> was ultimately passed through. > > Jacek and I have been digging into this on IRC, and he's been very > helpful in trying to get further, but we're still stuck. We tried to > be more introspective, inserting strace both as "strace script wine" > and as "script strace wine". We tried running just "wine a.exe" > without any extra glue, and logging the raw SSH packets from putty. > After many iterations on these and other tests, Jacek finally had the > idea to try removing Windows entirely from the equation, and we ran > with a purely unix program / compiler combination: > > #include <unistd.h> > > int main() > { > write(1, "test\r\n", 6); > return 0; > } > > (and also as "test\n", 5) > > In both versions, the following was observed: > > case 1) ./a.out | xxd > case 2) script -c ./a.out out; xxd out > case 3) enable putting logging, ./a.out > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > So, is it possible after all of this back and forth regarding mingw, > wine, and others, that it's down to the write() system call that's > inserting extra \r's? Is this expected? I have reproduced this test with C. I suspect that the 'write' function was written to accommodate non standard behavior of windows which expects a CR-LF. This means that POSIX compliant code is adjusted by the C or gfortran libraries to emit a extra CR so that on Windows it will just work ok. So the test is doing exactly what you are telling it to do. An LF causes the run times to add a CR in front. With libgfortran I remember implementing some of this code myself and this is the reason, to keep applications happy on Windows. So the gfortran tests we wrote to accept either a CR or a CR-LF, and in the test code to only issue a normal line ending which on UNIX will be an LF and Windows an CR-LF. I lose track of details in between looking ta the test cases. let me know one of them to study that is gfortran side and will see what it is doing. Jerry ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-21 17:37 ` Jacek Caban 2022-12-22 1:01 ` NightStrike @ 2022-12-22 4:16 ` Jacob Bachmeyer 2022-12-22 8:40 ` Eric Pouech 1 sibling, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-22 4:16 UTC (permalink / raw) To: Jacek Caban; +Cc: fortran, NightStrike, Eric Pouech, DejaGnu mailing list [Bringing the DejaGnu list back into the discussion...] Jacek Caban wrote: > Hi all, > > > I'm responsible for Wine changes that cause your problems. I'm also > CCing Eric, who is Wine console expert, maybe he has better ideas. > Eric, see [1] if you're interested in the context. > > > Recent Wine versions implement Windows pseudo-consoles, see [2] for a > bit more details. It's generally Microsoft's semi-recent API that's > intended to be more compatible with POSIX than what was present in > previous versions of Windows. In theory, with that implemented, we > could just plug tty fds that we get from Unix and have Unix consoles > working using those Windows APIs. I would expect that to work very well with MinGW. > In practice, it's not quite as good as promised and we need some > tweaks to make it work nicely. We could improve those tweaks, but > there are architectural limitations that will come to play sooner or > later. Of course; "not quite as good as promised" seems to be a typical experience with Microsoft and their APIs. > > 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. > > > I think that it would not be enough. The way Windows consoles work is > that we manage complete internal screen buffer and emit output that > synchronizes the buffer with Unix terminal inside conhost.exe process. > It means that its output heavily processed and may be very different > from what application writes to its console handle. While escape codes > discussed in this thread are the most prominent difference (and that > part could, in theory, be improved on our side), there are more > differences. For example, if application writes "\rA\rB\rC", conhost > will process it, update its internal buffer which changes just one > character and cursor position, and emit sequence to update it in Unix > terminal, which could be just "\rC" (or even "C" if cursor was already > at the beginning of the line). Another example would be long lines: > conhost will emit additional EOLs instead of depending on embedder to > wrap the line. So conhost is essentially a Wine-specific screen(1) in that sense, except that it translates Windows screen buffer manipulations instead of VT100 escape codes? As I understand ncurses also implements most of this; perhaps simply delegating output to ncurses would solve the problem? If output were simply delegated to ncurses, (as I understand) setting TERM=dumb should be effective to eliminate escape codes from the output, since the "dumb" terminal does not support them. Alternately, could we have a "transparent" mode in conhost where most processing is bypassed? Setting TERM=dumb in the environment could reasonably activate this mode, or some other Wine-specific setting could be used. (maybe "WINETERM=raw"?) > I'm not really familiar with DejaGnu, but if you want to match > application output, that's probably not what you're looking for. DejaGnu is mostly designed to drive text-mode interactive programs through simulated user interactions, for which Expect is extremely useful, although the tests at issue here are simpler than this general case. Here, the compiler under test is used to build a test program, which is then run, its output collected, and that collected output compared to an expected pattern. In Windows terms (as I remember), this is equivalent to writing out a batch file that compiles a test program, then runs the test program with output redirected to a temporary file, running that batch file, and reading/checking the output file. POSIX allows DejaGnu to dispense with the batch file and the output temporary file. (If you think these issues are fun, wait until someone tries to test a MinGW port of GDB...) > The reason the previous workaround of compiling Wine without ncurses > worked is that if made Wine treat tty stdin/stdout in a way very > similar to regular pipes, so no extra processing was performed. This > was more of a side effect than a design choice. It should be possible > to provide some way to achieve that with the new Wine architecture. > I'm attaching an example of Wine patch that would allow it. With that > patch, you may disable conhost.exe (via winecfg or > WINEDLLOVERRIDES=conhost.exe=d environment variable) and achieve > something similar to previous workaround. If Wine makes proper use of ncurses, then setting TERM=dumb should have the effect of eliminating escape codes from the output. Why does it not do so? > Long term, I think that it would be best to get rid of console > behaviour expectations by using Windows build of DejaGnu. My > understanding is that it requires Cygwin, so the stack would be: > Windows DejaGnu on Cygwin on Wine on Linux. This would make all > similar mismatches in expectations non-existent. Cygwin is tricky to > run on Wine, there are a few known problems like [3], but we're > getting there. That could also introduce new problems, since it would be relying on Expect's Windows port. (DejaGnu happens to work on Windows because Expect is portable to Windows, or at least Cygwin.) There are some ongoing efforts to reduce gratuitous POSIX dependencies in DejaGnu, i.e. to use Tcl's portability aids where appropriate, mostly because using [file join $a $b $c] (for example) clearly indicates that $a, $b, and $c are file names, while simply [join [list $a $b $c] "/"] or "$a/$b/$c" says nothing about the meaning of the operation. > Jacek > > > [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html > > [2] > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > > > [3] https://bugs.winehq.org/show_bug.cgi?id=47808 -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-22 4:16 ` Jacob Bachmeyer @ 2022-12-22 8:40 ` Eric Pouech 2022-12-23 3:51 ` Jacob Bachmeyer 0 siblings, 1 reply; 44+ messages in thread From: Eric Pouech @ 2022-12-22 8:40 UTC (permalink / raw) To: jcb62281, Jacek Caban; +Cc: fortran, NightStrike, DejaGnu mailing list Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : > >> I think that it would not be enough. The way Windows consoles work is >> that we manage complete internal screen buffer and emit output that >> synchronizes the buffer with Unix terminal inside conhost.exe >> process. It means that its output heavily processed and may be very >> different from what application writes to its console handle. While >> escape codes discussed in this thread are the most prominent >> difference (and that part could, in theory, be improved on our side), >> there are more differences. For example, if application writes >> "\rA\rB\rC", conhost will process it, update its internal buffer >> which changes just one character and cursor position, and emit >> sequence to update it in Unix terminal, which could be just "\rC" (or >> even "C" if cursor was already at the beginning of the line). Another >> example would be long lines: conhost will emit additional EOLs >> instead of depending on embedder to wrap the line. > > So conhost is essentially a Wine-specific screen(1) in that sense, > except that it translates Windows screen buffer manipulations instead > of VT100 escape codes? As I understand ncurses also implements most > of this; perhaps simply delegating output to ncurses would solve the > problem? If output were simply delegated to ncurses, (as I > understand) setting TERM=dumb should be effective to eliminate escape > codes from the output, since the "dumb" terminal does not support them. unfortunately, things are not as simple as that: on one hand we need to mimic Windows behavior, and on the other hand let apps running in wine behave like regular posix applications <g> (Note: conhost(.exe) is not wine specific, it's part of the way windows handle the console input/output) but I agree that wine should provide a (simple) way to disable windows' console for cases like this > > Alternately, could we have a "transparent" mode in conhost where most > processing is bypassed? Setting TERM=dumb in the environment could > reasonably activate this mode, or some other Wine-specific setting > could be used. (maybe "WINETERM=raw"?) an alternate solution to Jacob's patch is to run wine with none of the fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 from console). So something like ./wine what_ever_you_need | tee /dev/null 2>1 < /dev/null would do HTH ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-22 8:40 ` Eric Pouech @ 2022-12-23 3:51 ` Jacob Bachmeyer 2022-12-23 23:32 ` Jacek Caban 2023-01-04 15:21 ` Pedro Alves 0 siblings, 2 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-23 3:51 UTC (permalink / raw) To: Eric Pouech; +Cc: Jacek Caban, fortran, NightStrike, DejaGnu mailing list Eric Pouech wrote: > Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : >>> I think that it would not be enough. The way Windows consoles work >>> is that we manage complete internal screen buffer and emit output >>> that synchronizes the buffer with Unix terminal inside conhost.exe >>> process. It means that its output heavily processed and may be very >>> different from what application writes to its console handle. While >>> escape codes discussed in this thread are the most prominent >>> difference (and that part could, in theory, be improved on our >>> side), there are more differences. For example, if application >>> writes "\rA\rB\rC", conhost will process it, update its internal >>> buffer which changes just one character and cursor position, and >>> emit sequence to update it in Unix terminal, which could be just >>> "\rC" (or even "C" if cursor was already at the beginning of the >>> line). Another example would be long lines: conhost will emit >>> additional EOLs instead of depending on embedder to wrap the line. >> >> So conhost is essentially a Wine-specific screen(1) in that sense, >> except that it translates Windows screen buffer manipulations instead >> of VT100 escape codes? As I understand ncurses also implements most >> of this; perhaps simply delegating output to ncurses would solve the >> problem? If output were simply delegated to ncurses, (as I >> understand) setting TERM=dumb should be effective to eliminate escape >> codes from the output, since the "dumb" terminal does not support them. > > unfortunately, things are not as simple as that: on one hand we need > to mimic Windows behavior, and on the other hand let apps running in > wine behave like regular posix applications <g> > > (Note: conhost(.exe) is not wine specific, it's part of the way > windows handle the console input/output) Right. So that is the name of the program that manages consoles in Windows. I knew it was not cmd.exe itself. I was testing an understanding that conhost.exe in Wine is essentially similar to GNU screen, in that both emulate a console/terminal using a *nix terminal. If so, then it should be possible to delegate the actual output (including reductions like the example "\rA\rB\rC" to "\rC") to the ncurses library and get proper sensitivity to TERM "for free" as well. To do that, conhost.exe would need to translate the Windows console buffer manipulations into curses operations, or possibly lower-level terminfo operations, if you still want to roll your own optimization code. If this were done, you could check if the current terminal has sufficient support to properly emulate a Windows console and switch to "raw" mode if the needed terminfo capabilities are not found. Setting TERM=dumb in the environment would then force the use of "raw" mode. > but I agree that wine should provide a (simple) way to disable > windows' console for cases like this Jacek Caban mentioned Windows pseudo-consoles, apparently a new feature. Would those be a better "fit" for this type of scenario or are they considerably more complex than POSIX ptys and the apparent equivalence is false? Does the pseudo-console appear like a regular console to the child process or does the child need special support to run with a pseudo-console? >> Alternately, could we have a "transparent" mode in conhost where most >> processing is bypassed? Setting TERM=dumb in the environment could >> reasonably activate this mode, or some other Wine-specific setting >> could be used. (maybe "WINETERM=raw"?) > an alternate solution to Jacob's patch is to run wine with none of the > fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 > from console). So something like ./wine what_ever_you_need | tee > /dev/null 2>1 < /dev/null would do The problem with this solution in general is that Expect does not normally use the shell to spawn subprocesses, although the shell could be explicitly invoked (as "/bin/sh -c '...'"). Fortunately, in the specific case that is causing this issue at the moment, the programs tested are not being run interactively, so it would be possible to use Tcl's open(n), which uses a pipe, instead of Expect's spawn, which uses a pty. Running the program is done by a callback in testsuite code, rather than the DejaGnu framework itself, so any patch here needs to be applied to the testsuite. Note that this workaround only works for non-interactive programs; it will not work when someone decides they want to test MinGW GDB using Wine. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-23 3:51 ` Jacob Bachmeyer @ 2022-12-23 23:32 ` Jacek Caban 2022-12-24 5:33 ` Jacob Bachmeyer 2023-01-04 15:21 ` Pedro Alves 1 sibling, 1 reply; 44+ messages in thread From: Jacek Caban @ 2022-12-23 23:32 UTC (permalink / raw) To: jcb62281, Eric Pouech; +Cc: fortran, NightStrike, DejaGnu mailing list On 12/23/22 04:51, Jacob Bachmeyer wrote: > Eric Pouech wrote: >> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : >>>> I think that it would not be enough. The way Windows consoles work >>>> is that we manage complete internal screen buffer and emit output >>>> that synchronizes the buffer with Unix terminal inside conhost.exe >>>> process. It means that its output heavily processed and may be very >>>> different from what application writes to its console handle. While >>>> escape codes discussed in this thread are the most prominent >>>> difference (and that part could, in theory, be improved on our >>>> side), there are more differences. For example, if application >>>> writes "\rA\rB\rC", conhost will process it, update its internal >>>> buffer which changes just one character and cursor position, and >>>> emit sequence to update it in Unix terminal, which could be just >>>> "\rC" (or even "C" if cursor was already at the beginning of the >>>> line). Another example would be long lines: conhost will emit >>>> additional EOLs instead of depending on embedder to wrap the line. >>> >>> So conhost is essentially a Wine-specific screen(1) in that sense, >>> except that it translates Windows screen buffer manipulations >>> instead of VT100 escape codes? As I understand ncurses also >>> implements most of this; perhaps simply delegating output to ncurses >>> would solve the problem? If output were simply delegated to >>> ncurses, (as I understand) setting TERM=dumb should be effective to >>> eliminate escape codes from the output, since the "dumb" terminal >>> does not support them. >> >> unfortunately, things are not as simple as that: on one hand we need >> to mimic Windows behavior, and on the other hand let apps running in >> wine behave like regular posix applications <g> >> >> (Note: conhost(.exe) is not wine specific, it's part of the way >> windows handle the console input/output) > > Right. So that is the name of the program that manages consoles in > Windows. I knew it was not cmd.exe itself. I was testing an > understanding that conhost.exe in Wine is essentially similar to GNU > screen, in that both emulate a console/terminal using a *nix > terminal. If so, then it should be possible to delegate the actual > output (including reductions like the example "\rA\rB\rC" to "\rC") to > the ncurses library and get proper sensitivity to TERM "for free" as > well. > > To do that, conhost.exe would need to translate the Windows console > buffer manipulations into curses operations, or possibly lower-level > terminfo operations, if you still want to roll your own optimization > code. If this were done, you could check if the current terminal has > sufficient support to properly emulate a Windows console and switch to > "raw" mode if the needed terminfo capabilities are not found. Setting > TERM=dumb in the environment would then force the use of "raw" mode. Yes, an analogy to screen is right in many aspects, but there are also architectural difference that require implementation to be very different. ncurses operates on tty file descriptors backed by OS kernel. conhost needs to be able to operate on Windows names pipes, which are not associated with any file descriptor in Wine. Also my point was that if you capture the output sent by the application to the terminal and match that to a pattern, then any processing made by conhost could cause problems. Please correct me if I'm wrong, but my understanding is that, in the above hypothetical example, a test case doing printf(stdout, "\rA\rB\rC") and matching output to "\rA\rB\rC" would be considered valid (and fail on Wine). That's why we're trying to figure out a solution that bypasses conhost and makes the application write directly to stdout, like usual native application would do. Such mode would be less compatible with Windows, but if tests only does simple I/O and no other console interactions, it should work fine. Interpreting TERM=dumb would be a possible solution to enter that mode. Jacek ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-23 23:32 ` Jacek Caban @ 2022-12-24 5:33 ` Jacob Bachmeyer 2023-01-07 1:45 ` Jacek Caban 0 siblings, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2022-12-24 5:33 UTC (permalink / raw) To: Jacek Caban; +Cc: Eric Pouech, fortran, NightStrike, DejaGnu mailing list Jacek Caban wrote: > On 12/23/22 04:51, Jacob Bachmeyer wrote: >> Eric Pouech wrote: >>> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : >>>>> I think that it would not be enough. The way Windows consoles work >>>>> is that we manage complete internal screen buffer and emit output >>>>> that synchronizes the buffer with Unix terminal inside conhost.exe >>>>> process. It means that its output heavily processed and may be >>>>> very different from what application writes to its console handle. >>>>> While escape codes discussed in this thread are the most prominent >>>>> difference (and that part could, in theory, be improved on our >>>>> side), there are more differences. For example, if application >>>>> writes "\rA\rB\rC", conhost will process it, update its internal >>>>> buffer which changes just one character and cursor position, and >>>>> emit sequence to update it in Unix terminal, which could be just >>>>> "\rC" (or even "C" if cursor was already at the beginning of the >>>>> line). Another example would be long lines: conhost will emit >>>>> additional EOLs instead of depending on embedder to wrap the line. >>>> >>>> So conhost is essentially a Wine-specific screen(1) in that sense, >>>> except that it translates Windows screen buffer manipulations >>>> instead of VT100 escape codes? As I understand ncurses also >>>> implements most of this; perhaps simply delegating output to >>>> ncurses would solve the problem? If output were simply delegated >>>> to ncurses, (as I understand) setting TERM=dumb should be effective >>>> to eliminate escape codes from the output, since the "dumb" >>>> terminal does not support them. >>> >>> unfortunately, things are not as simple as that: on one hand we need >>> to mimic Windows behavior, and on the other hand let apps running in >>> wine behave like regular posix applications <g> >>> >>> (Note: conhost(.exe) is not wine specific, it's part of the way >>> windows handle the console input/output) >> >> Right. So that is the name of the program that manages consoles in >> Windows. I knew it was not cmd.exe itself. I was testing an >> understanding that conhost.exe in Wine is essentially similar to GNU >> screen, in that both emulate a console/terminal using a *nix >> terminal. If so, then it should be possible to delegate the actual >> output (including reductions like the example "\rA\rB\rC" to "\rC") >> to the ncurses library and get proper sensitivity to TERM "for free" >> as well. >> >> To do that, conhost.exe would need to translate the Windows console >> buffer manipulations into curses operations, or possibly lower-level >> terminfo operations, if you still want to roll your own optimization >> code. If this were done, you could check if the current terminal has >> sufficient support to properly emulate a Windows console and switch >> to "raw" mode if the needed terminfo capabilities are not found. >> Setting TERM=dumb in the environment would then force the use of >> "raw" mode. > > > Yes, an analogy to screen is right in many aspects, but there are also > architectural difference that require implementation to be very > different. ncurses operates on tty file descriptors backed by OS > kernel. conhost needs to be able to operate on Windows names pipes, > which are not associated with any file descriptor in Wine. Please explain this. Programs using curses make calls into the curses library, which ultimately produces I/O on a tty file descriptor. It seems to me that conhost is in the same position as the curses library: programs use Windows API calls for the console which [...across an IPC bridge of some type?...] result in dispatches in conhost that ultimately produce I/O on a tty file descriptor. Does conhost not actually hold the file descriptor, instead performing translations and sending the result back to the client process, which writes it out? If full curses is not usable for architectural reasons, terminfo would still be an improvement. Its setupterm() call may send any known init strings, but it could be given either the write end of a pipe or a file descriptor open on /dev/null if that is a problem. The terminfo database access functions tparm(), tigetflag(), tigetnum(), and tigetstr() all return values to their callers for further processing and the information needed to perform curses-style terminal initialization is stored as string capabilities in the terminfo database. > Also my point was that if you capture the output sent by the > application to the terminal and match that to a pattern, then any > processing made by conhost could cause problems. Please correct me if > I'm wrong, but my understanding is that, in the above hypothetical > example, a test case doing printf(stdout, "\rA\rB\rC") and matching > output to "\rA\rB\rC" would be considered valid (and fail on Wine). This type of thing is a general problem with testing curses programs, so the only difference would be effectively adding curses to programs that are not expected to use it. Yes, this could break testsuites that should work, so some kind of full bypass would be very helpful; you already have this if wine is run inside a pipeline. > That's why we're trying to figure out a solution that bypasses conhost > and makes the application write directly to stdout, like usual native > application would do. Such mode would be less compatible with Windows, > but if tests only does simple I/O and no other console interactions, > it should work fine. Interpreting TERM=dumb would be a possible > solution to enter that mode. I see two aspects to this, and I think both of them have value as improvements to Wine: 1. Programs that only use the standard handles (a la ISO C) probably do not /want/ full compatibility with Windows, so their I/O should be direct to the underlying POSIX fds. Note that line endings are still an issue here, but are /not/ Wine's problem---the program's I/O library module is generating Windows-style line endings because it was written for Windows. 2. Programs using Windows CUI probably should be mapped to curses; as I see it, conhost currently is implementing a subset of curses, poorly since it does not use terminfo. Wine should use curses if $TERM supports curses and either pop up an X11 Wine console window or bail out if a CUI call is made and $TERM does not support curses. (Actually, an option to explicitly select an X11 Wine console window might be helpful for people that want to invoke a Windows CUI program from a graphical menu; otherwise, you might end up with the CUI silently appearing on the console from which the X session was started... I know adding xterm to the mix solves this, but it is a use case.) I think the best goal here is that, for the standard handles, Wine I/O should be equivalent to a network connection (telnet?) to a Windows box. For CUI, Wine should actually use curses or at least terminfo, to allow the escape codes produced to match the user's terminal. The user's terminal might not always be a VT100-alike and custom simulated terminals could be very reasonable for testing curses TUI programs. (To my knowledge, there are as yet no testsuites that actually /do/ that, but the composition seems reasonable to me.) Finding that NightStrike's MinGW test cases are transparently using CUI would be a MinGW issue, not a Wine issue. It has been a long time since I have looked at Windows API, but I am guessing that there is both some equivalent to "fwrite(stdout, ...)" (ok, so likely something like "WriteToHandle(GetStandardHandle(STANDARD_HANDLE_OUTPUT),...)" if I remember the Windows API "style" and its affinity for RSI-supporting names correctly) and a more complex API for CUI that is more closely akin to curses. Could you delay initializing conhost until the program actually attempts to use CUI features? For this option, CUIInit() ends up calling newterm() and using curses if that succeeds, (possibly, after considerable future implementation effort) popping up a Wine console window using X11 if $DISPLAY is usable, or bailing out if neither way to get a full Windows console works. Until CUIInit() is called, the standard handles are just that and simply mapped through to the underlying POSIX handles. Is this architecturally feasible for Wine to do? -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-24 5:33 ` Jacob Bachmeyer @ 2023-01-07 1:45 ` Jacek Caban 2023-01-07 3:58 ` Jacob Bachmeyer 2023-01-08 6:47 ` NightStrike 0 siblings, 2 replies; 44+ messages in thread From: Jacek Caban @ 2023-01-07 1:45 UTC (permalink / raw) To: jcb62281; +Cc: Eric Pouech, fortran, NightStrike, DejaGnu mailing list [-- Attachment #1: Type: text/plain, Size: 10754 bytes --] Hi Jacob, Sorry for the delay. On 12/24/22 06:33, Jacob Bachmeyer wrote: > Jacek Caban wrote: >> On 12/23/22 04:51, Jacob Bachmeyer wrote: >>> Eric Pouech wrote: >>>> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : >>>>>> I think that it would not be enough. The way Windows consoles >>>>>> work is that we manage complete internal screen buffer and emit >>>>>> output that synchronizes the buffer with Unix terminal inside >>>>>> conhost.exe process. It means that its output heavily processed >>>>>> and may be very different from what application writes to its >>>>>> console handle. While escape codes discussed in this thread are >>>>>> the most prominent difference (and that part could, in theory, be >>>>>> improved on our side), there are more differences. For example, >>>>>> if application writes "\rA\rB\rC", conhost will process it, >>>>>> update its internal buffer which changes just one character and >>>>>> cursor position, and emit sequence to update it in Unix terminal, >>>>>> which could be just "\rC" (or even "C" if cursor was already at >>>>>> the beginning of the line). Another example would be long lines: >>>>>> conhost will emit additional EOLs instead of depending on >>>>>> embedder to wrap the line. >>>>> >>>>> So conhost is essentially a Wine-specific screen(1) in that sense, >>>>> except that it translates Windows screen buffer manipulations >>>>> instead of VT100 escape codes? As I understand ncurses also >>>>> implements most of this; perhaps simply delegating output to >>>>> ncurses would solve the problem? If output were simply delegated >>>>> to ncurses, (as I understand) setting TERM=dumb should be >>>>> effective to eliminate escape codes from the output, since the >>>>> "dumb" terminal does not support them. >>>> >>>> unfortunately, things are not as simple as that: on one hand we >>>> need to mimic Windows behavior, and on the other hand let apps >>>> running in wine behave like regular posix applications <g> >>>> >>>> (Note: conhost(.exe) is not wine specific, it's part of the way >>>> windows handle the console input/output) >>> >>> Right. So that is the name of the program that manages consoles in >>> Windows. I knew it was not cmd.exe itself. I was testing an >>> understanding that conhost.exe in Wine is essentially similar to GNU >>> screen, in that both emulate a console/terminal using a *nix >>> terminal. If so, then it should be possible to delegate the actual >>> output (including reductions like the example "\rA\rB\rC" to "\rC") >>> to the ncurses library and get proper sensitivity to TERM "for free" >>> as well. >>> >>> To do that, conhost.exe would need to translate the Windows console >>> buffer manipulations into curses operations, or possibly lower-level >>> terminfo operations, if you still want to roll your own optimization >>> code. If this were done, you could check if the current terminal >>> has sufficient support to properly emulate a Windows console and >>> switch to "raw" mode if the needed terminfo capabilities are not >>> found. Setting TERM=dumb in the environment would then force the >>> use of "raw" mode. >> >> >> Yes, an analogy to screen is right in many aspects, but there are >> also architectural difference that require implementation to be very >> different. ncurses operates on tty file descriptors backed by OS >> kernel. conhost needs to be able to operate on Windows names pipes, >> which are not associated with any file descriptor in Wine. > > Please explain this. Programs using curses make calls into the curses > library, which ultimately produces I/O on a tty file descriptor. It > seems to me that conhost is in the same position as the curses > library: programs use Windows API calls for the console which > [...across an IPC bridge of some type?...] result in dispatches in > conhost that ultimately produce I/O on a tty file descriptor. Does > conhost not actually hold the file descriptor, instead performing > translations and sending the result back to the client process, which > writes it out? There may be no file descriptor as far as conhost is concerned, it operates on generic Windows handles. For example, named pipes are purely a wineserver object (a shared process implementing some of kernel-alike tasks via IPC), there is no file descriptor involved. But when a file descriptor is available, it's optimized so that conhost holds fd and writes to it directly. It's an implementation details of a different layer. > If full curses is not usable for architectural reasons, terminfo would > still be an improvement. Its setupterm() call may send any known init > strings, but it could be given either the write end of a pipe or a > file descriptor open on /dev/null if that is a problem. See above, there may be no fd, so curses does not solve the problem. > The terminfo database access functions tparm(), tigetflag(), > tigetnum(), and tigetstr() all return values to their callers for > further processing and the information needed to perform curses-style > terminal initialization is stored as string capabilities in the > terminfo database. Yes, we should consider some form of better TERM compatibility. >> Also my point was that if you capture the output sent by the >> application to the terminal and match that to a pattern, then any >> processing made by conhost could cause problems. Please correct me if >> I'm wrong, but my understanding is that, in the above hypothetical >> example, a test case doing printf(stdout, "\rA\rB\rC") and matching >> output to "\rA\rB\rC" would be considered valid (and fail on Wine). > > This type of thing is a general problem with testing curses programs, > so the only difference would be effectively adding curses to programs > that are not expected to use it. Yes, this could break testsuites > that should work, so some kind of full bypass would be very helpful; > you already have this if wine is run inside a pipeline. > >> That's why we're trying to figure out a solution that bypasses >> conhost and makes the application write directly to stdout, like >> usual native application would do. Such mode would be less compatible >> with Windows, but if tests only does simple I/O and no other console >> interactions, it should work fine. Interpreting TERM=dumb would be a >> possible solution to enter that mode. > > I see two aspects to this, and I think both of them have value as > improvements to Wine: > > 1. Programs that only use the standard handles (a la ISO C) probably > do not /want/ full compatibility with Windows, so their I/O should be > direct to the underlying POSIX fds. Note that line endings are still > an issue here, but are /not/ Wine's problem---the program's I/O > library module is generating Windows-style line endings because it was > written for Windows. That's what my earlier patch allows. Note that there are weird implications like the fact that in this mode, a Windows equivalent of isatty(1) will return 0 and a number of Windows console functions will not work, so the setup would be kind of weird from Windows point of view. I'm afraid that it will not be satisfactory for more complex things (gdb?). > (Actually, an option to explicitly select an X11 Wine console window > might be helpful for people that want to invoke a Windows CUI program > from a graphical menu; otherwise, you might end up with the CUI > silently appearing on the console from which the X session was > started... I know adding xterm to the mix solves this, but it is a use > case.) Currently, you'd run it through wineconsole explicitly. And yes, it's not perfect and default behaviour could be improved, but it's challenging architecturally. There were some improvements to that code in current release cycle, which moved things in the right direction, but also proved this stuff to be hard to change without breaking anything. > I think the best goal here is that, for the standard handles, Wine I/O > should be equivalent to a network connection (telnet?) to a Windows > box. For CUI, Wine should actually use curses or at least terminfo, > to allow the escape codes produced to match the user's terminal. The > user's terminal might not always be a VT100-alike and custom simulated > terminals could be very reasonable for testing curses TUI programs. > (To my knowledge, there are as yet no testsuites that actually /do/ > that, but the composition seems reasonable to me.) As I said, compatibility with other terminals could be improved, but curses does not fit the role. Anyway, for sake of testing, the attached patch disables escapes hiding the cursor during screen updates which seem the most problematic. With this patch, some tests may work without disabling conhost (but other discussed problems are expected). > > Finding that NightStrike's MinGW test cases are transparently using > CUI would be a MinGW issue, not a Wine issue. > > It has been a long time since I have looked at Windows API, but I am > guessing that there is both some equivalent to "fwrite(stdout, ...)" > (ok, so likely something like > "WriteToHandle(GetStandardHandle(STANDARD_HANDLE_OUTPUT),...)" if I > remember the Windows API "style" and its affinity for RSI-supporting > names correctly) and a more complex API for CUI that is more closely > akin to curses. Could you delay initializing conhost until the > program actually attempts to use CUI features? For this option, > CUIInit() ends up calling newterm() and using curses if that succeeds, > (possibly, after considerable future implementation effort) popping up > a Wine console window using X11 if $DISPLAY is usable, or bailing out > if neither way to get a full Windows console works. Until CUIInit() > is called, the standard handles are just that and simply mapped > through to the underlying POSIX handles. > > Is this architecturally feasible for Wine to do? No, at least not without ugly hacks. Some decisions need to be made early, conhost can't just miss the first part of output. Going straight to conhost for handling POSIX tty so that console works as expected by Windows applications is what users want. Even if application doesn't need full compatibility, conhost still does the job (except for this very specific use case). BTW, if Expect ever plans a Windows port that's not based on Cygwin, it will likely need to use conhost-based pseudo consoles. It would then face exactly the same problem as when using Wine. Maybe long-term solution fits there? Problematic cursor hide/show escapes should be trivial to filter. Other differences may be more challenging. Thanks, Jacek [-- Attachment #2: conhost.diff --] [-- Type: text/x-patch, Size: 522 bytes --] diff --git a/programs/conhost/conhost.c b/programs/conhost/conhost.c index 769f998f404..dd04640d570 100644 --- a/programs/conhost/conhost.c +++ b/programs/conhost/conhost.c @@ -195,7 +195,7 @@ static void *tty_alloc_buffer( struct console *console, size_t size ) static void hide_tty_cursor( struct console *console ) { - if (console->tty_cursor_visible) + if (console->tty_cursor_visible && !console->is_unix) { tty_write( console, "\x1b[?25l", 6 ); console->tty_cursor_visible = FALSE; ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-07 1:45 ` Jacek Caban @ 2023-01-07 3:58 ` Jacob Bachmeyer 2023-01-09 16:03 ` Jacek Caban 2023-01-08 6:47 ` NightStrike 1 sibling, 1 reply; 44+ messages in thread From: Jacob Bachmeyer @ 2023-01-07 3:58 UTC (permalink / raw) To: Jacek Caban; +Cc: Eric Pouech, fortran, NightStrike, DejaGnu mailing list Jacek Caban wrote: > Hi Jacob, > > Sorry for the delay. Not a problem. > On 12/24/22 06:33, Jacob Bachmeyer wrote: >> Jacek Caban wrote: >> > [...] > > >> The terminfo database access functions tparm(), tigetflag(), >> tigetnum(), and tigetstr() all return values to their callers for >> further processing and the information needed to perform curses-style >> terminal initialization is stored as string capabilities in the >> terminfo database. > > Yes, we should consider some form of better TERM compatibility. I still suggest using terminfo here. This seems to be exactly the problem it is supposed to solve. >>> Also my point was that if you capture the output sent by the >>> application to the terminal and match that to a pattern, then any >>> processing made by conhost could cause problems. Please correct me >>> if I'm wrong, but my understanding is that, in the above >>> hypothetical example, a test case doing printf(stdout, "\rA\rB\rC") >>> and matching output to "\rA\rB\rC" would be considered valid (and >>> fail on Wine). >> >> This type of thing is a general problem with testing curses programs, >> so the only difference would be effectively adding curses to programs >> that are not expected to use it. Yes, this could break testsuites >> that should work, so some kind of full bypass would be very helpful; >> you already have this if wine is run inside a pipeline. >> >>> That's why we're trying to figure out a solution that bypasses >>> conhost and makes the application write directly to stdout, like >>> usual native application would do. Such mode would be less >>> compatible with Windows, but if tests only does simple I/O and no >>> other console interactions, it should work fine. Interpreting >>> TERM=dumb would be a possible solution to enter that mode. >> >> I see two aspects to this, and I think both of them have value as >> improvements to Wine: >> >> 1. Programs that only use the standard handles (a la ISO C) probably >> do not /want/ full compatibility with Windows, so their I/O should be >> direct to the underlying POSIX fds. Note that line endings are still >> an issue here, but are /not/ Wine's problem---the program's I/O >> library module is generating Windows-style line endings because it >> was written for Windows. > > That's what my earlier patch allows. Note that there are weird > implications like the fact that in this mode, a Windows equivalent of > isatty(1) will return 0 and a number of Windows console functions will > not work, so the setup would be kind of weird from Windows point of > view. I'm afraid that it will not be satisfactory for more complex > things (gdb?). It would probably be a good idea to map the Windows equivalent of isatty(3) to the underlying isatty(3) call in this mode, so that an underlying pty will be correctly reflected, although this is a future improvement. As for the setup being kind of weird from a Windows point of view, I suggest comparing it to the scenario of running a program under a telnet session on a Windows host, prior to the introduction of pseudoconsoles, which I understand was also quite weird by Windows standards. >> (Actually, an option to explicitly select an X11 Wine console window >> might be helpful for people that want to invoke a Windows CUI program >> from a graphical menu; otherwise, you might end up with the CUI >> silently appearing on the console from which the X session was >> started... I know adding xterm to the mix solves this, but it is a >> use case.) > > Currently, you'd run it through wineconsole explicitly. And yes, it's > not perfect and default behaviour could be improved, but it's > challenging architecturally. There were some improvements to that code > in current release cycle, which moved things in the right direction, > but also proved this stuff to be hard to change without breaking anything. I see. >> I think the best goal here is that, for the standard handles, Wine >> I/O should be equivalent to a network connection (telnet?) to a >> Windows box. For CUI, Wine should actually use curses or at least >> terminfo, to allow the escape codes produced to match the user's >> terminal. The user's terminal might not always be a VT100-alike and >> custom simulated terminals could be very reasonable for testing >> curses TUI programs. (To my knowledge, there are as yet no >> testsuites that actually /do/ that, but the composition seems >> reasonable to me.) > > > As I said, compatibility with other terminals could be improved, but > curses does not fit the role. Anyway, for sake of testing, the > attached patch disables escapes hiding the cursor during screen > updates which seem the most problematic. With this patch, some tests > may work without disabling conhost (but other discussed problems are > expected). Agreed that curses may not be feasible for Wine to use, but terminfo would still be a good solution to replace the hardcoded terminal escape strings in conhost. > [...] > > BTW, if Expect ever plans a Windows port that's not based on Cygwin, > it will likely need to use conhost-based pseudo consoles. It would > then face exactly the same problem as when using Wine. Maybe long-term > solution fits there? Problematic cursor hide/show escapes should be > trivial to filter. Other differences may be more challenging. My understanding is that Expect does not have a native Windows port precisely because Windows, until recently, did not have ptys or anything like them. Those other differences may still preclude a native Windows port of Expect. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-07 3:58 ` Jacob Bachmeyer @ 2023-01-09 16:03 ` Jacek Caban 2023-01-10 9:19 ` NightStrike 2023-01-11 2:44 ` Jacob Bachmeyer 0 siblings, 2 replies; 44+ messages in thread From: Jacek Caban @ 2023-01-09 16:03 UTC (permalink / raw) To: jcb62281; +Cc: Eric Pouech, fortran, NightStrike, DejaGnu mailing list Hi Jacob, On 1/7/23 04:58, Jacob Bachmeyer wrote: >> On 12/24/22 06:33, Jacob Bachmeyer wrote: >>> Jacek Caban wrote: >>> >> [...] >> >> >>> The terminfo database access functions tparm(), tigetflag(), >>> tigetnum(), and tigetstr() all return values to their callers for >>> further processing and the information needed to perform >>> curses-style terminal initialization is stored as string >>> capabilities in the terminfo database. >> >> Yes, we should consider some form of better TERM compatibility. > > I still suggest using terminfo here. This seems to be exactly the > problem it is supposed to solve. Yes, that's something we should look into. >>>> Also my point was that if you capture the output sent by the >>>> application to the terminal and match that to a pattern, then any >>>> processing made by conhost could cause problems. Please correct me >>>> if I'm wrong, but my understanding is that, in the above >>>> hypothetical example, a test case doing printf(stdout, "\rA\rB\rC") >>>> and matching output to "\rA\rB\rC" would be considered valid (and >>>> fail on Wine). >>> >>> This type of thing is a general problem with testing curses >>> programs, so the only difference would be effectively adding curses >>> to programs that are not expected to use it. Yes, this could break >>> testsuites that should work, so some kind of full bypass would be >>> very helpful; you already have this if wine is run inside a pipeline. >>> >>>> That's why we're trying to figure out a solution that bypasses >>>> conhost and makes the application write directly to stdout, like >>>> usual native application would do. Such mode would be less >>>> compatible with Windows, but if tests only does simple I/O and no >>>> other console interactions, it should work fine. Interpreting >>>> TERM=dumb would be a possible solution to enter that mode. >>> >>> I see two aspects to this, and I think both of them have value as >>> improvements to Wine: >>> >>> 1. Programs that only use the standard handles (a la ISO C) >>> probably do not /want/ full compatibility with Windows, so their I/O >>> should be direct to the underlying POSIX fds. Note that line >>> endings are still an issue here, but are /not/ Wine's problem---the >>> program's I/O library module is generating Windows-style line >>> endings because it was written for Windows. >> >> That's what my earlier patch allows. Note that there are weird >> implications like the fact that in this mode, a Windows equivalent of >> isatty(1) will return 0 and a number of Windows console functions >> will not work, so the setup would be kind of weird from Windows point >> of view. I'm afraid that it will not be satisfactory for more complex >> things (gdb?). > > It would probably be a good idea to map the Windows equivalent of > isatty(3) to the underlying isatty(3) call in this mode, so that an > underlying pty will be correctly reflected, although this is a future > improvement. As for the setup being kind of weird from a Windows > point of view, I suggest comparing it to the scenario of running a > program under a telnet session on a Windows host, prior to the > introduction of pseudoconsoles, which I understand was also quite > weird by Windows standards. For isatty alone it's not impossible, bit also not as easy as it may seem. In our usual conhost mode, this just works very differently and only conhost operates of actual host tty fds (a good analogy for this is how Linux driver 'writes' to pty master device), so isatty() itself operates on handles that don't have native tty fds associated. Making this work without conhost for Windows isatty() itself could be done, but it's way more tricky for lower level console APIs. For example something like this: if (VerifyConsoleIoHandle(handle)) WriteConsole(handle, ...); else WriteFile(handle, ...); is a valid logic on Windows (this is how msvcrt write() works). If we somehow hack VerifyConsoleIoHandle to return TRUE in this special mode, things would break unless we'd also support WriteConsole(), so we'd then need more hacks to support that as well. And if we really want to support even more low level functions properly, we need conhost. >> [...] >> >> BTW, if Expect ever plans a Windows port that's not based on Cygwin, >> it will likely need to use conhost-based pseudo consoles. It would >> then face exactly the same problem as when using Wine. Maybe >> long-term solution fits there? Problematic cursor hide/show escapes >> should be trivial to filter. Other differences may be more challenging. > > My understanding is that Expect does not have a native Windows port > precisely because Windows, until recently, did not have ptys or > anything like them. Those other differences may still preclude a > native Windows port of Expect. Sure, I'd be interested how well my latest patch works for NightStrike. It should give us overview about how much conhost interferes with test results in practice when we get easy stuff out of the way. Thanks, Jacek ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-09 16:03 ` Jacek Caban @ 2023-01-10 9:19 ` NightStrike 2023-01-11 9:10 ` NightStrike 2023-01-11 18:41 ` NightStrike 2023-01-11 2:44 ` Jacob Bachmeyer 1 sibling, 2 replies; 44+ messages in thread From: NightStrike @ 2023-01-10 9:19 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, Eric Pouech, fortran, DejaGnu mailing list On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote: > Sure, I'd be interested how well my latest patch works for NightStrike. > It should give us overview about how much conhost interferes with test > results in practice when we get easy stuff out of the way. Generally, more tests run and pass, but most still fail for different reasons. IOW, the cursor hiding escapes are gone, but the EOLs still don't match until we modify the tests themselves. Here are the result summaries, full logs available to anyone who wants them. Unmodified Wine 7.20: === gcc Summary === # of expected passes 166686 # of unexpected failures 1865 # of unexpected successes 12 # of expected failures 1226 # of unresolved testcases 787 # of unsupported tests 3111 === gfortran Summary === # of expected passes 66391 # of unexpected failures 637 # of unexpected successes 8 # of expected failures 257 # of unresolved testcases 6 # of unsupported tests 247 === g++ Summary === # of expected passes 218092 # of unexpected failures 1410 # of unexpected successes 4 # of expected failures 2149 # of unresolved testcases 63 # of unsupported tests 11318 === gm2 Summary === # of expected passes 7126 # of unexpected failures 2563 # of unresolved testcases 2065 === libatomic Summary === # of expected passes 53 # of unexpected failures 1 === libstdc++ Summary === # of expected passes 14139 # of unexpected failures 474 # of unexpected successes 2 # of expected failures 98 # of unresolved testcases 1 # of unsupported tests 835 === rust Summary === # of expected passes 4565 # of unexpected failures 403 # of expected failures 39 Modified Wine 7.20 using your latest one liner patch: === gcc Summary === # of expected passes 168207 # of unexpected failures 1867 # of unexpected successes 12 # of expected failures 1235 # of unresolved testcases 760 # of unsupported tests 3118 === gfortran Summary === # of expected passes 66409 # of unexpected failures 619 # of unexpected successes 8 # of expected failures 257 # of unresolved testcases 6 # of unsupported tests 247 === g++ Summary === # of expected passes 220403 # of unexpected failures 1116 # of unexpected successes 4 # of expected failures 2063 # of unresolved testcases 47 # of unsupported tests 10978 === gm2 Summary === # of expected passes 7126 # of unexpected failures 2563 # of unresolved testcases 2065 === libatomic Summary === # of expected passes 53 # of unexpected failures 1 runtest completed at Tue Jan 10 00:05:49 2023 === libstdc++ Summary === # of expected passes 14139 # of unexpected failures 474 # of unexpected successes 2 # of expected failures 98 # of unresolved testcases 1 # of unsupported tests 835 === rust Summary === # of expected passes 4568 # of unexpected failures 394 # of expected failures 39 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-10 9:19 ` NightStrike @ 2023-01-11 9:10 ` NightStrike 2023-01-11 18:41 ` NightStrike 1 sibling, 0 replies; 44+ messages in thread From: NightStrike @ 2023-01-11 9:10 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, Eric Pouech, fortran, DejaGnu mailing list Better presentation thanks to Jacob On Tue, Jan 10, 2023 at 4:19 AM NightStrike <nightstrike@gmail.com> wrote: > > On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote: > > Sure, I'd be interested how well my latest patch works for NightStrike. > > It should give us overview about how much conhost interferes with test > > results in practice when we get easy stuff out of the way. > > Generally, more tests run and pass, but most still fail for different > reasons. IOW, the cursor hiding escapes are gone, but the EOLs still > don't match until we modify the tests themselves. Here are the result > summaries, full logs available to anyone who wants them. > > Unmodified Wine 7.20: __________________________________________________ / PASS FAIL ?PASS ?FAIL UNSUP UNRES UNTEST |-------------------------------------------------- gcc | 166638 1765 12 1226 3107 787 0 !E! gfortran | 64445 608 8 238 247 6 0 gm2 | 7126 2563 0 0 0 2065 0 g++ | 217936 1336 4 2144 11318 63 0 !E! !W! libatomic | 53 1 0 0 0 0 0 !W! libstdc++ | 14139 263 2 93 835 1 0 rust | 4185 403 0 39 0 0 0 !W! |-------------------------------------------------- | 474522 6939 26 3740 15507 2922 0 \__________________________________________________ > Modified Wine 7.20 using your latest one liner patch: __________________________________________________ / PASS FAIL ?PASS ?FAIL UNSUP UNRES UNTEST |-------------------------------------------------- gcc | 168207 1867 12 1235 3118 760 0 !E! !W! gfortran | 66403 619 8 257 247 6 0 !W! gm2 | 7126 2563 0 0 0 2065 0 g++ | 220403 1116 4 2063 10978 47 0 !E! !W! libatomic | 53 1 0 0 0 0 0 !W! libstdc++ | 14139 474 2 98 835 1 0 !W! rust | 4568 394 0 39 0 0 0 !W! |-------------------------------------------------- | 480899 7034 26 3692 15178 2879 0 \__________________________________________________ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-10 9:19 ` NightStrike 2023-01-11 9:10 ` NightStrike @ 2023-01-11 18:41 ` NightStrike 2023-01-14 23:36 ` NightStrike 1 sibling, 1 reply; 44+ messages in thread From: NightStrike @ 2023-01-11 18:41 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, Eric Pouech, fortran, DejaGnu mailing list [-- Attachment #1: Type: text/plain, Size: 764 bytes --] On Tue, Jan 10, 2023, 04:19 NightStrike <nightstrike@gmail.com> wrote: > On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote: > > Sure, I'd be interested how well my latest patch works for NightStrike. > > It should give us overview about how much conhost interferes with test > > results in practice when we get easy stuff out of the way. > > Generally, more tests run and pass, but most still fail for different > reasons. IOW, the cursor hiding escapes are gone, but the EOLs still > don't match until we modify the tests themselves. > Quick update that I found more tests that fail with what I assume are Wine escape codes, K and C. (Ie ^[[K). I can't figure out under what context they appear, and I don't know what they are for. > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-11 18:41 ` NightStrike @ 2023-01-14 23:36 ` NightStrike 0 siblings, 0 replies; 44+ messages in thread From: NightStrike @ 2023-01-14 23:36 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, Eric Pouech, fortran, DejaGnu mailing list On Wed, Jan 11, 2023 at 1:41 PM NightStrike <nightstrike@gmail.com> wrote: > > > > On Tue, Jan 10, 2023, 04:19 NightStrike <nightstrike@gmail.com> wrote: >> >> On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote: >> > Sure, I'd be interested how well my latest patch works for NightStrike. >> > It should give us overview about how much conhost interferes with test >> > results in practice when we get easy stuff out of the way. >> >> Generally, more tests run and pass, but most still fail for different >> reasons. IOW, the cursor hiding escapes are gone, but the EOLs still >> don't match until we modify the tests themselves. > > > Quick update that I found more tests that fail with what I assume are Wine escape codes, K and C. (Ie ^[[K). I can't figure out under what context they appear, and I don't know what they are for. With Jacek's latest patch: __________________________________________________ / PASS FAIL ?PASS ?FAIL UNSUP UNRES UNTEST |-------------------------------------------------- acats | 0 0 0 0 0 0 0 gcc | 164293 1652 6 1150 3213 810 0 !E! !W! gdc | 4167 1658 0 0 1553 121 0 gfortran | 66811 210 8 257 247 0 0 !W! gm2 | 1168 6673 0 0 0 2065 0 gnat | 3360 24 0 23 14 0 0 !W! g++ | 226182 1314 4 2346 10900 89 0 !E! !W! libatomic | 53 1 0 0 0 0 0 !W! libstdc++ | 14563 50 26 74 835 1 0 !W! obj-c++ | 1502 8 1 1 79 0 0 !W! objc | 1882 9 0 6 70 10 0 !E! rust | 4148 432 0 39 0 0 0 !W! |-------------------------------------------------- | 488129 12031 45 3896 16911 3096 0 \__________________________________________________ We're making good progress here! (Note that the numbers above for rust are for the gcc master branch, but every line ending failure is fixed on the rust dev branch, leaving only 1 actual bug) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-09 16:03 ` Jacek Caban 2023-01-10 9:19 ` NightStrike @ 2023-01-11 2:44 ` Jacob Bachmeyer 1 sibling, 0 replies; 44+ messages in thread From: Jacob Bachmeyer @ 2023-01-11 2:44 UTC (permalink / raw) To: Jacek Caban; +Cc: Eric Pouech, fortran, NightStrike, DejaGnu mailing list Jacek Caban wrote: > On 1/7/23 04:58, Jacob Bachmeyer wrote: >>> On 12/24/22 06:33, Jacob Bachmeyer wrote: >>>> Jacek Caban wrote: >>>> >>> [...] >>>>> Also my point was that if you capture the output sent by the >>>>> application to the terminal and match that to a pattern, then any >>>>> processing made by conhost could cause problems. Please correct me >>>>> if I'm wrong, but my understanding is that, in the above >>>>> hypothetical example, a test case doing printf(stdout, >>>>> "\rA\rB\rC") and matching output to "\rA\rB\rC" would be >>>>> considered valid (and fail on Wine). >>>> >>>> This type of thing is a general problem with testing curses >>>> programs, so the only difference would be effectively adding curses >>>> to programs that are not expected to use it. Yes, this could break >>>> testsuites that should work, so some kind of full bypass would be >>>> very helpful; you already have this if wine is run inside a pipeline. >>>> >>>>> That's why we're trying to figure out a solution that bypasses >>>>> conhost and makes the application write directly to stdout, like >>>>> usual native application would do. Such mode would be less >>>>> compatible with Windows, but if tests only does simple I/O and no >>>>> other console interactions, it should work fine. Interpreting >>>>> TERM=dumb would be a possible solution to enter that mode. >>>> >>>> I see two aspects to this, and I think both of them have value as >>>> improvements to Wine: >>>> >>>> 1. Programs that only use the standard handles (a la ISO C) >>>> probably do not /want/ full compatibility with Windows, so their >>>> I/O should be direct to the underlying POSIX fds. Note that line >>>> endings are still an issue here, but are /not/ Wine's problem---the >>>> program's I/O library module is generating Windows-style line >>>> endings because it was written for Windows. >>> >>> That's what my earlier patch allows. Note that there are weird >>> implications like the fact that in this mode, a Windows equivalent >>> of isatty(1) will return 0 and a number of Windows console functions >>> will not work, so the setup would be kind of weird from Windows >>> point of view. I'm afraid that it will not be satisfactory for more >>> complex things (gdb?). >> >> It would probably be a good idea to map the Windows equivalent of >> isatty(3) to the underlying isatty(3) call in this mode, so that an >> underlying pty will be correctly reflected, although this is a future >> improvement. As for the setup being kind of weird from a Windows >> point of view, I suggest comparing it to the scenario of running a >> program under a telnet session on a Windows host, prior to the >> introduction of pseudoconsoles, which I understand was also quite >> weird by Windows standards. > > > For isatty alone it's not impossible, bit also not as easy as it may > seem. In our usual conhost mode, this just works very differently and > only conhost operates of actual host tty fds (a good analogy for this > is how Linux driver 'writes' to pty master device), so isatty() itself > operates on handles that don't have native tty fds associated. Making > this work without conhost for Windows isatty() itself could be done, > but it's way more tricky for lower level console APIs. For example > something like this: > > if (VerifyConsoleIoHandle(handle)) > > WriteConsole(handle, ...); > > else > > WriteFile(handle, ...); > > is a valid logic on Windows (this is how msvcrt write() works). If we > somehow hack VerifyConsoleIoHandle to return TRUE in this special > mode, things would break unless we'd also support WriteConsole(), so > we'd then need more hacks to support that as well. And if we really > want to support even more low level functions properly, we need conhost. Wait... Windows has handles that clearly have distinct types but does not actually have a universal write()? [... rant elided ...] Now this is starting to look like the best approach would be a special console mode similar to a pseudoconsole, selected by an explicit command-line option when Wine is started, that does not emit the normal escape sequences, ignores TERM, and is effectively just a pass-through to a raw POSIX fd. This will /not/ work correctly if the tested program tries to use much more than the simple WriteConsole(), but would be explicitly documented as existing for testing purposes, not for regular use, so losing cursor motion and collapsing all output into a single stream in chronological order seems reasonable. If I understand correctly, this /would/ work for testing GDB: the GDB tests run GDB in a line-oriented mode. -- Jacob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-07 1:45 ` Jacek Caban 2023-01-07 3:58 ` Jacob Bachmeyer @ 2023-01-08 6:47 ` NightStrike 1 sibling, 0 replies; 44+ messages in thread From: NightStrike @ 2023-01-08 6:47 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, Eric Pouech, fortran, DejaGnu mailing list On Fri, Jan 6, 2023 at 8:46 PM Jacek Caban <jacek@codeweavers.com> wrote: > As I said, compatibility with other terminals could be improved, but > curses does not fit the role. Anyway, for sake of testing, the attached > patch disables escapes hiding the cursor during screen updates which > seem the most problematic. With this patch, some tests may work without > disabling conhost (but other discussed problems are expected). I can confirm that with this patch, the "^[[?25l" sequences are gone and ^M^M still remains. So at least this is a less intrusive version of the first patch that can hopefully be easily upstreamed. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2022-12-23 3:51 ` Jacob Bachmeyer 2022-12-23 23:32 ` Jacek Caban @ 2023-01-04 15:21 ` Pedro Alves 2023-01-04 15:45 ` Eric Pouech 1 sibling, 1 reply; 44+ messages in thread From: Pedro Alves @ 2023-01-04 15:21 UTC (permalink / raw) To: jcb62281, Eric Pouech Cc: Jacek Caban, fortran, NightStrike, DejaGnu mailing list On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote: > it will not work when someone decides they want to test MinGW GDB using Wine. This has been on my wish list for years. Unfortunately, I can't even get plain cross-compiled MinGW GDB working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines of input. E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') : $ $ wine ./gdb.exe ... This GDB was configured as "x86_64-w64-mingw32". ... (gdb) foobar<ret> << a new line is printed << more <ret> << C-j is the same ^CQuit << ctrl-c works (gdb) ^Z [2]+ Stopped wine ./gdb.exe $ killall gdb.exe ( I've tried this occasionally in the past decade, always with the same result. ) If someone knows a workaround for this, I'd be curious to learn about it. :-) Last time I tried, GDBserver worked OK under Wine, and I could connect ("(gdb) target remote ...") a linux-hosted GDB built with cross Windows debugging support to that GDBserver and debug fine. So the Windows debug API seemed to work well enough under Wine, which seemed quite promising. It's just the native Windows GDB (and the Windows readline port, I guess) that doesn't seem to accept/recognize newlines for some reason. I figure that once we're past that hurdle, testing MinGW GDB under Wine under linux-hosted DejaGnu would become possible... Pedro Alves ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-04 15:21 ` Pedro Alves @ 2023-01-04 15:45 ` Eric Pouech 2023-01-04 15:52 ` Pedro Alves 0 siblings, 1 reply; 44+ messages in thread From: Eric Pouech @ 2023-01-04 15:45 UTC (permalink / raw) To: Pedro Alves, jcb62281 Cc: Jacek Caban, fortran, NightStrike, DejaGnu mailing list Le 04/01/2023 à 16:21, Pedro Alves a écrit : > On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote: >> it will not work when someone decides they want to test MinGW GDB using Wine. > This has been on my wish list for years. Unfortunately, I can't even get plain cross-compiled MinGW GDB > working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines > of input. > > E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') : hi they've been a couple of improvements in Wine 7.x that will help here so upgrading might be a solution (wine 8.0 is likely to be released by the end of this month...). wine 6.x tree is two year old :-( (notepad is wine's notepad) ------------------------------------------- [eric:~/work/output-wine/wine64]$ ./wine --version wine-8.0-rc2-14-g48c0a75432b [eric:~/work/output-wine/wine64]$ ./wine /usr/x86_64-w64-mingw32/sys-root/mingw/bin/gdb.exe notepad GNU gdb (GDB) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from notepad... (gdb) b WinMain Breakpoint 1 at 0x140005280: file /home/eric/work/wine/programs/notepad/main.c, line 845. (gdb) run Starting program: C:\windows\system32\notepad.exe Breakpoint 1, WinMain (hInstance=0x140000000, prev=prev@entry=0x0, cmdline=cmdline@entry=0x34a3b2 "", show=show@entry=1) at /home/eric/work/wine/programs/notepad/main.c:845 845 { (gdb) bt #0 WinMain (hInstance=0x140000000, prev=prev@entry=0x0, cmdline=cmdline@entry=0x34a3b2 "", show=show@entry=1) at /home/eric/work/wine/programs/notepad/main.c:845 #1 0x0000000140006d25 in main (argc=<optimized out>, argv=<optimized out>) at /home/eric/work/wine/dlls/msvcrt/crt_winmain.c:53 (gdb) b CreateWindowExW Breakpoint 2 at 0x216a25ee0: CreateWindowExW. (2 locations) (gdb) c Continuing. Breakpoint 2, 0x0000000216a25ee0 in CreateWindowExW () at /home/eric/work/wine/dlls/user32/win.c:443 443 } (gdb) bt #0 0x0000000216a25ee0 in CreateWindowExW () at /home/eric/work/wine/dlls/user32/win.c:443 #1 0x000000014000560a in WinMain (hInstance=0x140000000, prev=prev@entry=0x0, cmdline=cmdline@entry=0x34a3b2 "", show=show@entry=1) at /home/eric/work/wine/programs/notepad/main.c:893 #2 0x0000000140006d25 in main (argc=<optimized out>, argv=<optimized out>) at /home/eric/work/wine/dlls/msvcrt/crt_winmain.c:53 (gdb) q A debugging session is active. Inferior 1 [process 508] will be killed. Quit anyway? (y or n) y [eric:~/work/output-wine/wine64]$ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: testsuite under wine 2023-01-04 15:45 ` Eric Pouech @ 2023-01-04 15:52 ` Pedro Alves 0 siblings, 0 replies; 44+ messages in thread From: Pedro Alves @ 2023-01-04 15:52 UTC (permalink / raw) To: Eric Pouech, jcb62281 Cc: Jacek Caban, fortran, NightStrike, DejaGnu mailing list On 2023-01-04 3:45 p.m., Eric Pouech wrote: > Le 04/01/2023 à 16:21, Pedro Alves a écrit : >> On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote: >>> it will not work when someone decides they want to test MinGW GDB using Wine. >> This has been on my wish list for years. Unfortunately, I can't even get plain cross-compiled MinGW GDB >> working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines >> of input. >> >> E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') : > > hi > > they've been a couple of improvements in Wine 7.x that will help here > > so upgrading might be a solution (wine 8.0 is likely to be released by the end of this month...). wine 6.x tree is two year old :-( ... > > (notepad is wine's notepad) > > ------------------------------------------- > > [eric:~/work/output-wine/wine64]$ ./wine --version > wine-8.0-rc2-14-g48c0a75432b > [eric:~/work/output-wine/wine64]$ ./wine /usr/x86_64-w64-mingw32/sys-root/mingw/bin/gdb.exe notepad > GNU gdb (GDB) 12.1 (snip gdb working as expected) Woo, awesome & finally! Thanks a lot. ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2023-01-14 23:36 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-16 2:20 testsuite under wine NightStrike 2022-12-16 6:44 ` Thomas Koenig 2022-12-17 0:26 ` NightStrike 2022-12-17 10:52 ` Thomas Koenig 2022-12-17 23:24 ` NightStrike 2022-12-18 3:44 ` Jacob Bachmeyer 2022-12-18 21:13 ` NightStrike 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON 2022-12-19 11:00 ` NightStrike 2022-12-19 11:13 ` NightStrike 2022-12-20 3:51 ` Jacob Bachmeyer 2022-12-21 17:37 ` Jacek Caban 2022-12-22 1:01 ` NightStrike 2022-12-22 4:37 ` Jacob Bachmeyer 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 2023-01-11 2:30 ` Jacob Bachmeyer 2023-01-11 9:33 ` NightStrike 2023-01-12 4:11 ` Jacob Bachmeyer 2023-01-06 3:41 ` Jerry D 2022-12-22 4:16 ` Jacob Bachmeyer 2022-12-22 8:40 ` Eric Pouech 2022-12-23 3:51 ` Jacob Bachmeyer 2022-12-23 23:32 ` Jacek Caban 2022-12-24 5:33 ` Jacob Bachmeyer 2023-01-07 1:45 ` Jacek Caban 2023-01-07 3:58 ` Jacob Bachmeyer 2023-01-09 16:03 ` Jacek Caban 2023-01-10 9:19 ` NightStrike 2023-01-11 9:10 ` NightStrike 2023-01-11 18:41 ` NightStrike 2023-01-14 23:36 ` NightStrike 2023-01-11 2:44 ` Jacob Bachmeyer 2023-01-08 6:47 ` NightStrike 2023-01-04 15:21 ` Pedro Alves 2023-01-04 15:45 ` Eric Pouech 2023-01-04 15:52 ` Pedro Alves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).