Mingw gdb validation

Mingw gdb validation

[Denis PILAT]

Is there any chance for such a patch to be accepted ?
It allows the following test to be successful when using a MinGW gdb 
(means a gdb compiled under MSYS environment or using 
CFLAGS="-mno-cygwin" under cygwin).

If yes I will write a correct changelog entry.
The following $nl value is the only one that works both on linux and 
windows when running a validation.


About  gdb.cp/userdef.exp, I don't understand why only in part of the 
tests we have a \r\n expected as the answer ?
gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}"
gdb_test "print one && two" "\\\$\[0-9\]* = 1\[\r\n\]"    <===== Why 
expecting \r\n here  and not above ?


-- 
Denis

Index: ovldbreak.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/ovldbreak.exp,v
retrieving revision 1.10
diff -u -p -r1.10 ovldbreak.exp
--- ovldbreak.exp       3 Apr 2008 21:42:33 -0000       1.10
+++ ovldbreak.exp       17 Oct 2008 12:12:41 -0000
@@ -22,6 +22,7 @@
 # tests for overloaded member functions. Set breakpoints on
 # overloaded member functions
 #
+set nl "\[\r\n\]*"


 if $tracelevel then {
@@ -130,7 +131,7 @@ proc set_bp_overloaded {name expectedmen
 # Note the arg type variations on lines 6 and 13.
 # This accommodates different versions of g++.

-set menu_overload1arg "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::overload1arg\\(double\\) at.*$srcfile:121\r\n\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120\r\n\\\[4\\\] foo::overload1arg\\(unsigned long\\) at.*$srcfile:119\r\n\\\[5\\\] foo::overload1arg\\(long\\) at.*$srcfile:118\r\n\\\[6\\\] foo::overload1arg\\((unsigned int|unsigned)\\) at.*$srcfile:117\r\n\\\[7\\\] foo::overload1arg\\(int\\) at.*$srcfile:116\r\n\\\[8\\\] foo::overload1arg\\(unsigned short\\) at.*$srcfile:115\r\n\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114\r\n\\\[10\\\] foo::overload1arg\\(unsigned char\\) at.*$srcfile:113\r\n\\\[11\\\] foo::overload1arg\\(signed char\\) at.*$srcfile:112\r\n\\\[12\\\] foo::overload1arg\\(char\\) at.*$srcfile:111\r\n\\\[13\\\] foo::overload1arg\\((void|)\\) at.*$srcfile:110\r\n> $"
+set menu_overload1arg "\\\[0\\\] cancel$nl\\\[1\\\] all$nl\\\[2\\\] foo::overload1arg\\(double\\) at.*$srcfile:121$nl\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120$nl\\\[4\\\] foo::overload1arg\\(unsigned long\\) at.*$srcfile:119$nl\\\[5\\\] foo::overload1arg\\(long\\) at.*$srcfile:118$nl\\\[6\\\] foo::overload1arg\\((unsigned int|unsigned)\\) at.*$srcfile:117$nl\\\[7\\\] foo::overload1arg\\(int\\) at.*$srcfile:116$nl\\\[8\\\] foo::overload1arg\\(unsigned short\\) at.*$srcfile:115$nl\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114$nl\\\[10\\\] foo::overload1arg\\(unsigned char\\) at.*$srcfile:113$nl\\\[11\\\] foo::overload1arg\\(signed char\\) at.*$srcfile:112$nl\\\[12\\\] foo::overload1arg\\(char\\) at.*$srcfile:111$nl\\\[13\\\] foo::overload1arg\\((void|)\\) at.*$srcfile:110$nl> $"

 # Set multiple-symbols to "ask", to allow us to test the use
 # of the multiple-choice menu when breaking on an overloaded method.
Index: userdef.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/userdef.exp,v
retrieving revision 1.10
diff -u -p -r1.10 userdef.exp
--- userdef.exp 1 Jan 2008 22:53:19 -0000       1.10
+++ userdef.exp 17 Oct 2008 12:12:41 -0000
@@ -19,6 +19,7 @@
 #
 # source file "userdef.cc"
 #
+set nl "\[\r\n\]*"

 if $tracelevel then {
         strace $tracelevel
@@ -94,9 +95,9 @@ gdb_test "print one / two" "\\\$\[0-9\]*

 gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}"

-gdb_test "print one && two" "\\\$\[0-9\]* = 1\[\r\n\]"
+gdb_test "print one && two" "\\\$\[0-9\]* = 1$nl"

-gdb_test "print one || two" "\\\$\[0-9\]* = 1\[\r\n\]"
+gdb_test "print one || two" "\\\$\[0-9\]* = 1$nl"

 gdb_test "print one & two" "\\\$\[0-9\]* = {x = 0, y = 1}"

@@ -104,17 +105,17 @@ gdb_test "print one | two" "\\\$\[0-9\]*

 gdb_test "print one ^ two" "\\\$\[0-9\]* = {x = 6, y = 6}"

-gdb_test "print one < two" "\\\$\[0-9\]* = 1\[\r\n\]"
+gdb_test "print one < two" "\\\$\[0-9\]* = 1$nl"

-gdb_test "print one <= two" "\\\$\[0-9\]* = 1\[\r\n\]"
+gdb_test "print one <= two" "\\\$\[0-9\]* = 1$nl"

-gdb_test "print one > two" "\\\$\[0-9\]* = 0\[\r\n\]"
+gdb_test "print one > two" "\\\$\[0-9\]* = 0$nl"

-gdb_test "print one >= two" "\\\$\[0-9\]* = 0\[\r\n\]"
+gdb_test "print one >= two" "\\\$\[0-9\]* = 0$nl"

-gdb_test "print one == two" "\\\$\[0-9\]* = 0\[\r\n\]"
+gdb_test "print one == two" "\\\$\[0-9\]* = 0$nl"

-gdb_test "print one != two" "\\\$\[0-9\]* = 1\[\r\n\]"
+gdb_test "print one != two" "\\\$\[0-9\]* = 1$nl"

 # Can't really check the output of this one without knowing
 # target integer width.  Make sure we don't try to call
@@ -124,7 +125,7 @@ gdb_test "print one << 31" "\\\$\[0-9\]*
 # Should be fine even on < 32-bit targets.
 gdb_test "print one >> 31" "\\\$\[0-9\]* = {x = 0, y = 0}"

-gdb_test "print !one" "\\\$\[0-9\]* = 0\[\r\n\]"
+gdb_test "print !one" "\\\$\[0-9\]* = 0$nl"

 # Assumes 2's complement.  So does everything...
 gdb_test "print +one" "\\\$\[0-9\]* = {x = 2, y = 3}"

RE: Mingw gdb validation

[Pierre Muller]

  I thought about this a while ago also,
and I was wondering if the best solution would not be to
have a global nl variable defined in gdb.exp
that would depend on the target you are testing.
  I also thought at that time that we should
define two global variables: nl and nls.
"nl" as being something that is a single newline 
defined generally as "\[\r\n\]" but probably as "\[\r\n\]\n?" for mingw32
and
"nls" if more than one newline is allowed and should generally be simply
"\[\r\n\]*"

  Once these two variables are set in gdb.exp,
we should replace every "\[\r\n\]*" by a "$nls"
and all \[\r\n\]" by "$nl" in the expected answer part of the tests.


   This should allow a lot of currently failing mingw32 test
to succeed.
 It would also have the advantage of not changing
anything for other targets, unless we find other targets that
would benefit from a similar change, but that could then also
be inserted in gdb.exp special cases for nl and nls variables.

  Nevertheless, changing all tests to use nl and nls
is probably not an easy task...


Pierre Muller
Pascal language support maintainer for GDB

 
  

Re: Mingw gdb validation

[Denis PILAT]

Pierre Muller wrote:
>   I thought about this a while ago also,
> and I was wondering if the best solution would not be to
> have a global nl variable defined in gdb.exp
> that would depend on the target you are testing.
>   I also thought at that time that we should
> define two global variables: nl and nls.
> "nl" as being something that is a single newline 
> defined generally as "\[\r\n\]" but probably as "\[\r\n\]\n?" for mingw32
> and
> "nls" if more than one newline is allowed and should generally be simply
> "\[\r\n\]*"
>   
If it's more than one we should use "\[\r\n\]+".

>   Once these two variables are set in gdb.exp,
> we should replace every "\[\r\n\]*" by a "$nls"
> and all \[\r\n\]" by "$nl" in the expected answer part of the tests.
>
>
>    This should allow a lot of currently failing mingw32 test
> to succeed.
>  It would also have the advantage of not changing
> anything for other targets, unless we find other targets that
> would benefit from a similar change, but that could then also
> be inserted in gdb.exp special cases for nl and nls variables.
>
>   Nevertheless, changing all tests to use nl and nls
> is probably not an easy task...
>   
That's just a long task, but I think it's easier than understanding why 
some tests require end-of-line testing, and some tests do not. See my 
previous mail about gdb.cp/userdef.exp.
I'm afraid there could be some tests that has been written to match the 
gdb behavior, even if it was not a correct behavior.
 
Denis

Re: Mingw gdb validation

[Daniel Jacobowitz]

On Mon, Oct 20, 2008 at 10:40:55AM +0200, Denis PILAT wrote:
> Is there any chance for such a patch to be accepted ?
> It allows the following test to be successful when using a MinGW gdb  
> (means a gdb compiled under MSYS environment or using  
> CFLAGS="-mno-cygwin" under cygwin).

That depends why it's necessary... we have been testing mingw GDB
binaries for at least a year, and I've never seen this failure.
Are you using a Cygwin expect binary to drive the GDB?

> If yes I will write a correct changelog entry.
> The following $nl value is the only one that works both on linux and  
> windows when running a validation.
>
>
> About  gdb.cp/userdef.exp, I don't understand why only in part of the  
> tests we have a \r\n expected as the answer ?
> gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}"
> gdb_test "print one && two" "\\\$\[0-9\]* = 1\[\r\n\]"    <===== Why  
> expecting \r\n here  and not above ?

I don't know either, there it can probably be removed.  It was
probably to ensure that there wasn't another character after the 1,
but gdb_test already does that.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Mingw gdb validation

[Pedro Alves]

On Wednesday 22 October 2008 14:26:06, Daniel Jacobowitz wrote:
> On Mon, Oct 20, 2008 at 10:40:55AM +0200, Denis PILAT wrote:
> > Is there any chance for such a patch to be accepted ?
> > It allows the following test to be successful when using a MinGW gdb  
> > (means a gdb compiled under MSYS environment or using  
> > CFLAGS="-mno-cygwin" under cygwin).
> 
> That depends why it's necessary... we have been testing mingw GDB
> binaries for at least a year, and I've never seen this failure.

IIRC, we have a local patch that forces GDB's stdout/stderr to
binary mode, thus avoiding all these \r\n issues.

> Are you using a Cygwin expect binary to drive the GDB?

-- 
Pedro Alves

Re: Mingw gdb validation

[Denis PILAT]

Daniel Jacobowitz wrote:
> On Mon, Oct 20, 2008 at 10:40:55AM +0200, Denis PILAT wrote:
>   
>> Is there any chance for such a patch to be accepted ?
>> It allows the following test to be successful when using a MinGW gdb  
>> (means a gdb compiled under MSYS environment or using  
>> CFLAGS="-mno-cygwin" under cygwin).
>>     
>
> That depends why it's necessary... we have been testing mingw GDB
> binaries for at least a year, and I've never seen this failure.
> Are you using a Cygwin expect binary to drive the GDB?
>   
No I'm using ActiveState version of expect.
I didn't know it was possible to test non-cygwin GDBs in a cygwin 
environment. Each time I tried in the previous years, it fails.
Is there any specific stuff do apart from running runtest ?
>   
>> If yes I will write a correct changelog entry.
>> The following $nl value is the only one that works both on linux and  
>> windows when running a validation.
>>
>>
>> About  gdb.cp/userdef.exp, I don't understand why only in part of the  
>> tests we have a \r\n expected as the answer ?
>> gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}"
>> gdb_test "print one && two" "\\\$\[0-9\]* = 1\[\r\n\]"    <===== Why  
>> expecting \r\n here  and not above ?
>>     
>
> I don't know either, there it can probably be removed.  It was
> probably to ensure that there wasn't another character after the 1,
> but gdb_test already does that.
>   
Thanks, that's an explanation.
Denis

RE: Mingw gdb validation

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Denis PILAT
> Envoyé : Wednesday, October 22, 2008 3:04 PM
> À : Pierre Muller
> Cc : 'gdb-patches'
> Objet : Re: Mingw gdb validation
> 
> 
> 
> Pierre Muller wrote:
> >   I thought about this a while ago also,
> > and I was wondering if the best solution would not be to
> > have a global nl variable defined in gdb.exp
> > that would depend on the target you are testing.
> >   I also thought at that time that we should
> > define two global variables: nl and nls.
> > "nl" as being something that is a single newline
> > defined generally as "\[\r\n\]" but probably as "\[\r\n\]\n?" for
> mingw32
> > and
> > "nls" if more than one newline is allowed and should generally be
> simply
> > "\[\r\n\]*"
> >
> If it's more than one we should use "\[\r\n\]+".

  I agree 
grep -o '\\\[\\r\\n\\\]+' | wc -l
gives me 654 matching's for "\[\r\n\]+" pattern
nevertheless,
grep -o '\\\[\\r\\n\\\]\*' | wc -l
also finds 47 matchs for "\[\r\n\]*" pattern.
Finally 
grep -o '\\\[\\r\\n\\\]\*' | wc -l
gives me 1048 matching's...
Lengthy work indeed, but rather straightforward
if we can write a bullet-proof sed substitution rule...


So maybe we would really need three variants:
one for "\[\r\n\]+"
one for "\[\r\n\]*"
and a third one for all other "\[\r\n\]" appearances...

 By the way, there is also one "\[\n\r\]" occurrence:
in gdb.stabs/exclfwd.exp: set eol "\[ \t\]*\[\n\r\]+"

which, despite being semantically equal to the usual "\[\r\n\]"
pattern used, could be forgotten in the change...

  Maybe we can create a group even for the
special mingw case that would allow the + and *
modifiers in the regular expressions to work as expected...
  But the trickiness on regular expression inside
expect (or is it tcl per-se?) 

> >   Nevertheless, changing all tests to use nl and nls
> > is probably not an easy task...
> >
> That's just a long task, but I think it's easier than understanding why
> some tests require end-of-line testing, and some tests do not. See my
> previous mail about gdb.cp/userdef.exp.
  I completely agree with you here,
  I would not like to try to understand for each individual 
use of the "\[\r\n\]" pattern, why it was inserted
and why there is (or is not) a '*' or '+' modifier on it!

> I'm afraid there could be some tests that has been written to match the
> gdb behavior, even if it was not a correct behavior.

  I hope that, if we are able to generate
a loooong single patch containing all those
changes and have no effect on the testsuite results
on a ordinary target, it would be very unlikely that
we break anything on other targets.

  But of course, we need to get feedback from
our global maintainers on that issue.


Pierre Muller
Pascal language support maintainer for GDB