Re: RFA: patch to fix gdb/1680

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

drow> Does it work if you put a backslash in front of them instead?  That's
drow> clearer to read, IMO.

On my machine (expect 5.41):

  "{...}"      ERROR: Process no longer exists
  "\{...\}"    ERROR: Process no longer exists
  "\\{...\\}"  Works fine

> This had better work, or the entire C++ testsuite is in trouble.

Something freaky is going on, indeed.

Empirically, the C++ test suite is working fine.  For example,
these tests:

  # gdb.cp/class2.exp

    # Access the "A" object.

    gdb_test "print alpha" \
	"= {.*a1 = 100.*}" \
	"print alpha at marker return 0"

    # Access the "B" object.

    gdb_test "print beta" \
	"= {.*a1 = 200.*b1 = 201.*b2 = 202}" \
	"print beta at marker return 0"

  # gdb.cp/derivation.exp

    gdb_test "print a_instance" "\\$\[0-9\]+ = \{a = 1, aa = 2\}" "print value of a_instance"

  # gdb.cp/userdef.exp

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

I spent about two hours playing with the braces in i386-sse.exp.
I truly don't understand why the code i386-sse.exp barfs out when
all that code in gdb.cp/*.exp works.  But I'm sure it works on
my systems (native i686-pc-linux-gnu and native hppa2.0w-hp-hpux11.11),
with expect 5.41.  And it's working on other people's systems in
gdb-testers@ ; I presume most of those results are with the sourceware
version of expect (based on expect 5.26).

I definitely want Jim's patch so that i386-sse.exp does its job.
If you insist, we could make PR gdb/1680 suspended instead of
closing it, to remind us of this unsolved mystery.

Michael C

Re: RFA: patch to fix gdb/1680

[Andrew Cagney]

[added keiths who knows a lot more about tcl/tk]

> drow> Does it work if you put a backslash in front of them instead?  That's
> drow> clearer to read, IMO.
> 
> On my machine (expect 5.41):
> 
>   "{...}"      ERROR: Process no longer exists
>   "\{...\}"    ERROR: Process no longer exists
>   "\\{...\\}"  Works fine

Try "{}" instead of {""}.  In these sorts of situtations that works a 
lot better.

Andrew

Re: RFA: patch to fix gdb/1680

[Daniel Jacobowitz]

On Fri, Jun 18, 2004 at 03:18:36PM -0400, Michael Chastain wrote:
> drow> Does it work if you put a backslash in front of them instead?  That's
> drow> clearer to read, IMO.
> 
> On my machine (expect 5.41):
> 
>   "{...}"      ERROR: Process no longer exists
>   "\{...\}"    ERROR: Process no longer exists
>   "\\{...\\}"  Works fine

This error means that, somewhere, a syntax error has occured and
dejagnu has swallowed it.  I submitted a patch to DejaGNU to diagnose
this better and it was ignored in the general confusion that is DejaGNU
maintenance.

> I definitely want Jim's patch so that i386-sse.exp does its job.
> If you insist, we could make PR gdb/1680 suspended instead of
> closing it, to remind us of this unsolved mystery.

I prefer to solve the mystery instead.

If you pull that patch out of the DejaGNU list archives and apply it,
you will see:
ERROR OCCURED: couldn't compile regular expression pattern: invalid repetition count(s)

Presumably this version of TCL does not put special meaning on
{string}, but does on {NUMBER}, as has become fashionable for regex
engines.  When it sees {stringStartingWithADigit}, it tries to parse it
as a repetition count and throws an error.

Andrew writes:
> Try "{}" instead of {""}.  In these sorts of situtations that works a
> lot better.

which is the missing bit of my suggestion.  { and \{ are the same thing
when written in double quotes.  So (since we can't use {} here, because
there is a variable substitution inside gdb_test's argument), use two
backslashes.  That way one will reach the regex engine.

-- 
Daniel Jacobowitz

Re: RFA: patch to fix gdb/1680

[Andrew Cagney]

>>Try "{}" instead of {""}.  In these sorts of situtations that works a
>>> lot better.
> 
> 
> which is the missing bit of my suggestion.  { and \{ are the same thing
> when written in double quotes.  So (since we can't use {} here, because
> there is a variable substitution inside gdb_test's argument), use two
> backslashes.  That way one will reach the regex engine.

(two many quote characters).  Use ``{ ... }'' instead of ``" ... "'' 
when wrapping things up, it avoids the entire quoting et.al. problem.

Andrew

Re: RFA: patch to fix gdb/1680

[Daniel Jacobowitz]

On Fri, Jun 18, 2004 at 03:56:42PM -0400, Andrew Cagney wrote:
> >>Try "{}" instead of {""}.  In these sorts of situtations that works a
> >>>lot better.
> >
> >
> >which is the missing bit of my suggestion.  { and \{ are the same thing
> >when written in double quotes.  So (since we can't use {} here, because
> >there is a variable substitution inside gdb_test's argument), use two
> >backslashes.  That way one will reach the regex engine.
> 
> (two many quote characters).  Use ``{ ... }'' instead of ``" ... "'' 
> when wrapping things up, it avoids the entire quoting et.al. problem.

I wrote:
> >when written in double quotes.  So (since we can't use {} here, because
> >there is a variable substitution inside gdb_test's argument), use two

If we use { }, the $r will not be expanded, and the test will not work. 
We can't use { } for this.

-- 
Daniel Jacobowitz

Re: RFA: patch to fix gdb/1680

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:

> On Fri, Jun 18, 2004 at 03:18:36PM -0400, Michael Chastain wrote:
> > drow> Does it work if you put a backslash in front of them instead?  That's
> > drow> clearer to read, IMO.
> > 
> > On my machine (expect 5.41):
> > 
> >   "{...}"      ERROR: Process no longer exists
> >   "\{...\}"    ERROR: Process no longer exists
> >   "\\{...\\}"  Works fine
> 
> This error means that, somewhere, a syntax error has occured and
> dejagnu has swallowed it.  I submitted a patch to DejaGNU to diagnose
> this better and it was ignored in the general confusion that is DejaGNU
> maintenance.
> 
> > I definitely want Jim's patch so that i386-sse.exp does its job.
> > If you insist, we could make PR gdb/1680 suspended instead of
> > closing it, to remind us of this unsolved mystery.
> 
> I prefer to solve the mystery instead.
> 
> If you pull that patch out of the DejaGNU list archives and apply it,
> you will see:
> ERROR OCCURED: couldn't compile regular expression pattern: invalid repetition count(s)
> 
> Presumably this version of TCL does not put special meaning on
> {string}, but does on {NUMBER}, as has become fashionable for regex
> engines.  When it sees {stringStartingWithADigit}, it tries to parse it
> as a repetition count and throws an error.

Ahh.  Here is a revision of my patch.  It is tested under the same
configuration as the original patch.

2004-06-17  Jim Blandy  <jimb@redhat.com>

        Fix PR testsuite/1680.
	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
	expressions.

Index: gdb/testsuite/gdb.arch/i386-sse.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/i386-sse.exp,v
retrieving revision 1.1
diff -c -p -r1.1 i386-sse.exp
*** gdb/testsuite/gdb.arch/i386-sse.exp	7 Jun 2004 15:38:52 -0000	1.1
--- gdb/testsuite/gdb.arch/i386-sse.exp	18 Jun 2004 22:15:52 -0000
*************** gdb_continue_to_breakpoint "continue to 
*** 71,77 ****
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = {$r, $r.25, $r.5, $r.75}.*" \
          "check contents of %xmm$r"
  }
  
--- 71,77 ----
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = \\{$r, $r.25, $r.5, $r.75\\}.*" \
          "check contents of %xmm$r"
  }
  
*************** gdb_continue_to_breakpoint "continue to 
*** 86,91 ****
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print data\[$r\]" \
!         ".. = {f = {[expr $r + 10], $r.25, $r.5, $r.75}}.*" \
          "check contents of data\[$r\]"
  }
--- 86,91 ----
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print data\[$r\]" \
!         ".. = \\{f = \\{[expr $r + 10], $r.25, $r.5, $r.75\\}\\}.*" \
          "check contents of data\[$r\]"
  }

Re: RFA: patch to fix gdb/1680

[Andreas Schwab]

Jim Blandy <jimb@redhat.com> writes:

> Ahh.  Here is a revision of my patch.  It is tested under the same
> configuration as the original patch.
>
> 2004-06-17  Jim Blandy  <jimb@redhat.com>
>
>         Fix PR testsuite/1680.
> 	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
> 	expressions.

How about "Quote curly braces in regular expressions"?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFA: patch to fix gdb/1680

[Jim Blandy]

Andreas Schwab <schwab@suse.de> writes:

> Jim Blandy <jimb@redhat.com> writes:
> 
> > Ahh.  Here is a revision of my patch.  It is tested under the same
> > configuration as the original patch.
> >
> > 2004-06-17  Jim Blandy  <jimb@redhat.com>
> >
> >         Fix PR testsuite/1680.
> > 	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
> > 	expressions.
> 
> How about "Quote curly braces in regular expressions"?

But that would describe my patch correctly.  Whose side are you on,
anyway?

(Thanks for noticing this; corrected as suggested.  And thanks to
Michael, too.)

2004-06-17  Jim Blandy  <jimb@redhat.com>

        Fix PR testsuite/1680.
	* gdb.arch/i386-sse.exp: Properly quote curly braces in
	regular expressions.

Index: gdb/testsuite/gdb.arch/i386-sse.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/i386-sse.exp,v
retrieving revision 1.1
diff -c -p -r1.1 i386-sse.exp
*** gdb/testsuite/gdb.arch/i386-sse.exp	7 Jun 2004 15:38:52 -0000	1.1
--- gdb/testsuite/gdb.arch/i386-sse.exp	18 Jun 2004 22:15:52 -0000
*************** gdb_continue_to_breakpoint "continue to 
*** 71,77 ****
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = {$r, $r.25, $r.5, $r.75}.*" \
          "check contents of %xmm$r"
  }
  
--- 71,77 ----
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = \\{$r, $r.25, $r.5, $r.75\\}.*" \
          "check contents of %xmm$r"
  }
  
*************** gdb_continue_to_breakpoint "continue to 
*** 86,91 ****
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print data\[$r\]" \
!         ".. = {f = {[expr $r + 10], $r.25, $r.5, $r.75}}.*" \
          "check contents of data\[$r\]"
  }
--- 86,91 ----
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print data\[$r\]" \
!         ".. = \\{f = \\{[expr $r + 10], $r.25, $r.5, $r.75\\}\\}.*" \
          "check contents of data\[$r\]"
  }

Re: RFA: patch to fix gdb/1680

[Jim Blandy]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:
> Approved.

Committed.

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

> Note, this duplication of the regexp engine is what I wrote about a 
> couple of weeks ago when removing expect first came up...

I found your message again after I posted mine ... now I feel dumb.
"Three months in the lab can often save thirty minutes in the library."

We're in pretty good shape with gdb because I've been using
stock TCL 8.4.6 + Expect 5.41 for a long time, years now.
So I've already swept the minefield, as it were.

> Finally, note that if you need to see the result regexp as it ACTUALLY 
> gets to dejagnu, pass the --debug flag in RUNTESTFLAGS, and it will 
> spit out a file named dbg.log in build/gdb/testsuite which shows among 
> much other stuff the actual regexp that dejagnu is trying to match.

Wow, I didn't know about that.  That will help me in the future.

Michael C

Re: RFA: patch to fix gdb/1680

[Jim Ingham]

Note, this duplication of the regexp engine is what I wrote about a 
couple of weeks ago when removing expect first came up...

In order not to have to change the Testsuites when Ian imported Tcl  
8.4 into the sourceware repository, he took an old copy of Tcl's regexp 
engine & stuffed it into expect.  This is not the way things work in 
the real versions of Tcl & Expect, needless to say.

The ChangeLog entry was:

2001-07-09  Ian Roxborough  <irox@redhat.com>

         * tclParse-compat.c: New file.
         * tcl_regexp.c:
         * tcl_regexp.h: New file.  Contains Tcl8.0's regexp.
         * Makefile.in: Added new files to be compiled and linked.
         * exp_clib.c (exp_expectl, exp_fexpectl):
         * exp_inter.c (in_keymap, Exp_InteractCmd ):
         * exp_regexp.c (regtry, regdump, regprop):
         * expect.c (parse_expect_args, eval_case_string,
           exp_background_filehandler, Exp_ExpectCmd):
         * expect.h:
         * expect_comm.h:
         * Dbg.c (breakpoint_test, cmdBreak): Use newly built in
           regexp, not external Tcl regexp.
         * exp_tty.c (exec_stty):
         * exp_command.c (Exp_CloseCmd, Tcl_CloseCmd): Handle Tcl API
           changes in Tcl8.3.

If you are going to use the net Tcl & Expect, you won't be able to do 
this hack, and are going to have to change the testsuite instead, as 
this thread is pointing out...

BTW, the regexp man page in the Tcl distro is quite exhaustive, for 
instance:

http://www.tcl.tk/man/tcl8.4/TclCmd/re_syntax.htm

This is a good reference for the 8.3 & above regexp syntax.

Note, also, if you don't need to substitute in variables, then it is 
MUCH easier to write the regexp expressions with {} around them that 
using "'s - since you don't have to worry about backslashing everything 
in sight...

And if you have a gnarly regexp you are trying to write that does need 
variables substituted, it can be easier to use the format command:

   foreach r {0 1 2 3 4 5 6 7} {
       set result_regex [format {.. = {%d, %d.25, %d.5, %d.75}.*} $r $r 
$r $r]
       gdb_test "print \$xmm$r.v4_float" \
          $result_regex \
           "check contents of %xmm$r"
   }

or if there are enough instances of one substituted value that it gets 
tedious to do the format, you can do:

   foreach r {0 1 2 3 4 5 6 7} {
       regsub -all {.. = {VAR, VAR.25, VAR.5, VAR.75}.*} VAR $r 
result_regexp
       gdb_test "print \$xmm$r.v4_float" \
          $result_regex \
           "check contents of %xmm$r"
   }

As I said, in this case the expression is pretty simple so the 
backslashing is not so onerous, but if you are doing something complex, 
either of these tricks can make the code much more readable...

Finally, note that if you need to see the result regexp as it ACTUALLY 
gets to dejagnu, pass the --debug flag in RUNTESTFLAGS, and it will 
spit out a file named dbg.log in build/gdb/testsuite which shows among 
much other stuff the actual regexp that dejagnu is trying to match.

Jim

On Jun 18, 2004, at 11:25 PM, Michael Elizabeth Chastain wrote:

> The problem is not with tcl, but with expect.
>
> I built two stacks of tcl+expect+dejagnu:
>
>   'released stack' -- all the packages from their ftp sites.
>   This is what I normally use.
>
>   'sourceware stack' -- the versions from sourceware.
>   This is what Jim B normally uses.
>
> Here is a version table:
>
> 	    released  sourceware
>   tcl       8.4.6     8.4.1 (nearly)
>   expect    5.41      5.26 + patches, dated 1998-06-15
>   dejagnu   1.4.4     1.4.3 (nearly)
>
> Both TCL and Expect have their own copies of the Henry Spencer regular
> expression code ("HSREC" for short).  You can see this coming: 
> "re-usable
> code re-used to hell".
>
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

Approved.

(Not sure if you're asking for approval for just the ChangeLog change,
but hey, I like saying it).

Michael C

===

2004-06-17  Jim Blandy  <jimb@redhat.com>

        Fix PR testsuite/1680.
	* gdb.arch/i386-sse.exp: Properly quote curly braces in
	regular expressions.

Re: RFA: patch to fix gdb/1680

[Joel Brobecker]

> So we have to write r.e.'s that work with both versions of HSREC.  We
> must be doing this right most of the time, because I don't see huge
> ERROR blotches in the files I've sampled from gdb-testers@ .

It may be not settled yet, but my impression was that sourceware
dejagnu/expect/tcl were to be removed pretty soon, no? If it is going
to be removed, then I would rather be in favor of requiring a version
of T+E+D that would allow quantifiers like ``{1,2}''.

So far, I was mostly annoyed by the decision to remove these sources
from src, especially with the little deadline that was initially
announced. But I must say that if I had to choose between the invenience
of disallowing ``{1,2}'' and the inconvenience of having to use a
(recent-enough) released version of TED, I'd rather go to a recent TED.

-- 
Joel

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

The problem is not with tcl, but with expect.

I built two stacks of tcl+expect+dejagnu:

  'released stack' -- all the packages from their ftp sites.
  This is what I normally use.

  'sourceware stack' -- the versions from sourceware.
  This is what Jim B normally uses.

Here is a version table:

	    released  sourceware
  tcl       8.4.6     8.4.1 (nearly)
  expect    5.41      5.26 + patches, dated 1998-06-15
  dejagnu   1.4.4     1.4.3 (nearly)

Both TCL and Expect have their own copies of the Henry Spencer regular
expression code ("HSREC" for short).  You can see this coming: "re-usable
code re-used to hell".

When I use the 'released' stack, the regular expressions in question
get interpreted by TCL's copy of HSREC.  This is a modern
R.E. compiler with support for braces like "[abc]{1,2}".  It chokes on:

	".. = {0, 0.25, 0.5, 0.75}.*" \

The TCL 8.4.6 and TCL 8.4.1 versions of HSREC are nearly identical,
(they better be because they are both 8.4.X).  They both choke on this.

However, with the sourceware stack, the TCL 8.4.1 HSREC is not even
used!  Instead, expect 5.26 uses its own HSREC.  This is from 1998,
and does not implement '{1,2}' count modifiers.

So we have to write r.e.'s that work with both versions of HSREC.  We
must be doing this right most of the time, because I don't see huge
ERROR blotches in the files I've sampled from gdb-testers@ .

Another question.  How about all those r.e's in gdb.cp such as:

  # gdb.cp/userdef.exp
  \\$[0-9]* = {x = -2, y = -2}

As Daniel J surmised, the HSREC lexer really does have code to
distinguish between "{0,2}" and "{x=0,y=2}".  I watched this code
getting called:

  case CHR('{'):
    ...
    if (ATEOS() || !iscdigit(*v->now)) {
      NOTE(REG_UBRACES);
      NOTE(REG_UUNSPEC);
      RETV(PLAIN,c);
    } else {
      NOTE(REG_UBOUNDS);
      INTOCON(L_EBND);
      RET('{');
    }

So I predict that this regular expression in i386-sse.exp would work fine
with both T+E+D stacks, because it will fool the lexer:

  ".. = {\[$r\], $r.25, $r.5, $r.75}."

And indeed this code works with both sourceware T+E+D and released T+E+D.
Of course, I don't want to see that code in the actual test script;
that was just a test.

I guess it's my job to write doco on "how to write a test script",
including all these quirks of regular expressions.  Sigh.

And finally, this patch is still approved:

  ".. = \\{$r, $r.25, $r.5, $r.75\\}."

Michael C

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

> Ahh.  Here is a revision of my patch.  It is tested under the same
> configuration as the original patch.

It works for me, too, with the stock released TCL+Expect+Dejagnu.

You gotta update the ChangeLog entry to match the patch.
With that update, this patch is approved.

I'm still futzing with a patched TCL+Expect+Dejagnu to get to the
bottom of '{' processing.  One thing I can say: tcl/generic/regcomp.c
is nearly identical between sourceware TCL and released TCL.
So it's something else in the call stack.  Whee.

Michael C

===

2004-06-17  Jim Blandy  <jimb@redhat.com>

        Fix PR testsuite/1680.
	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
	expressions.

Re: RFA: patch to fix gdb/1680

[Daniel Jacobowitz]

On Fri, Jun 18, 2004 at 04:25:24PM -0400, Michael Chastain wrote:
> drow> I prefer to solve the mystery instead.
> 
> We can do both.  I don't want to have 16 ERROR's in my face while
> we are figuring this out.
> 
> drow> Presumably this version of TCL does not put special meaning on
> drow> {string}, but does on {NUMBER}, as has become fashionable for regex
> drow> engines.
> 
> Aw, foo!  That's what's different about gdb.cp/*.exp.  All the examples
> in gdb.cp/*.exp are like:
> 
>   { x = 100, y = 101 }
> 
> Both the sourceware version of TCL (which is based on 8.4.1) and
> the version I use of TCL (8.4.6) have code for {NUMBER} and
> {NUMBER, NUMBER} modifiers.
> 
> I suspect there's some difference happening at the expect level
> (5.26 versus 5.41).
> 
> Time to dive into the TCL source and throw in some fprintf's and stuff.

The correct change is to use { \{ } } or " \\{ } "; it is harmless but
still incorrect where we use "\{ }" or "{ }" in the C++ testsuite.

I imagine it depends on the guts of the regex matcher whether " { 2, 0,
4 }" throws an error.

-- 
Daniel Jacobowitz

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

drow> I prefer to solve the mystery instead.

We can do both.  I don't want to have 16 ERROR's in my face while
we are figuring this out.

drow> Presumably this version of TCL does not put special meaning on
drow> {string}, but does on {NUMBER}, as has become fashionable for regex
drow> engines.

Aw, foo!  That's what's different about gdb.cp/*.exp.  All the examples
in gdb.cp/*.exp are like:

  { x = 100, y = 101 }

Both the sourceware version of TCL (which is based on 8.4.1) and
the version I use of TCL (8.4.6) have code for {NUMBER} and
{NUMBER, NUMBER} modifiers.

I suspect there's some difference happening at the expect level
(5.26 versus 5.41).

Time to dive into the TCL source and throw in some fprintf's and stuff.

Michael C

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

Literally, the test that blows up is:

  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
	  ".. = {$r, $r.25, $r.5, $r.75}.*" \
	  "check contents of %xmm$r"
  }

I ripped out most of the other meta-characters and this still blows up:

    gdb_test "print xmm0.v4_float" \
	".. = {0, 0.25, 0.5, 0.75}.*" \
	"check contents of xmm0"

"blows up" means:

  ERROR: Process no longer exists

What Daniel is saying, and I'm agreeing, is that gdb.cp/*.exp
has a lot of similar tests.  And they are not blowing up.

Michael C

Re: RFA: patch to fix gdb/1680

[Daniel Jacobowitz]

On Fri, Jun 18, 2004 at 01:10:10PM -0500, Jim Blandy wrote:
> 
> I tested it on my machine.  i686-pc-linux-gnu, gcc 3.3, dwarf-2 and
> stabs+.
> 
> Expect version is       5.26
> Tcl version is          8.4
> Framework version is    1.4.2.x
> 
> 2004-06-17  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
> 	expressions.

Does it work if you put a backslash in front of them instead?  That's
clearer to read, IMO.

This had better work, or the entire C++ testsuite is in trouble.

-- 
Daniel Jacobowitz

Re: RFA: patch to fix gdb/1680

[Michael Elizabeth Chastain]

Approved.

It works for me, too, with tcl 8.4.6, expect 5.41, dejagnu 1.4.4.
native i686-pc-linux-gnu, gcc 3.3.3, dwarf-2 and stabs+.

Err --- in the ChangeLog entry, add this line:

      Fix PR testsuite/1680.

Michael C

===

2004-06-17  Jim Blandy  <jimb@redhat.com>

	Fix PR testsuite/1680.
	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
	expressions.

RFA: patch to fix gdb/1680

[Jim Blandy]

I tested it on my machine.  i686-pc-linux-gnu, gcc 3.3, dwarf-2 and
stabs+.

Expect version is       5.26
Tcl version is          8.4
Framework version is    1.4.2.x

2004-06-17  Jim Blandy  <jimb@redhat.com>

	* gdb.arch/i386-sse.exp: Don't use curly braces in regular
	expressions.

Index: gdb/testsuite/gdb.arch/i386-sse.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/i386-sse.exp,v
retrieving revision 1.1
diff -c -p -r1.1 i386-sse.exp
*** gdb/testsuite/gdb.arch/i386-sse.exp	7 Jun 2004 15:38:52 -0000	1.1
--- gdb/testsuite/gdb.arch/i386-sse.exp	17 Jun 2004 22:55:22 -0000
*************** gdb_test "break [gdb_get_line_number "fi
*** 70,77 ****
  gdb_continue_to_breakpoint "continue to first breakpoint in main"
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = {$r, $r.25, $r.5, $r.75}.*" \
          "check contents of %xmm$r"
  }
  
--- 70,79 ----
  gdb_continue_to_breakpoint "continue to first breakpoint in main"
  
  foreach r {0 1 2 3 4 5 6 7} {
+     # Avoid using curly braces in regular expressions; different
+     # versions of Tcl treat them differently.
      gdb_test "print \$xmm$r.v4_float" \
!         ".. = .$r, $r.25, $r.5, $r.75..*" \
          "check contents of %xmm$r"
  }
  
*************** gdb_test "break [gdb_get_line_number "se
*** 85,91 ****
  gdb_continue_to_breakpoint "continue to second breakpoint in main"
  
  foreach r {0 1 2 3 4 5 6 7} {
      gdb_test "print data\[$r\]" \
!         ".. = {f = {[expr $r + 10], $r.25, $r.5, $r.75}}.*" \
          "check contents of data\[$r\]"
  }
--- 87,95 ----
  gdb_continue_to_breakpoint "continue to second breakpoint in main"
  
  foreach r {0 1 2 3 4 5 6 7} {
+     # Avoid using curly braces in regular expressions; different
+     # versions of Tcl treat them differently.
      gdb_test "print data\[$r\]" \
!         ".. = .f = .[expr $r + 10], $r.25, $r.5, $r.75...*" \
          "check contents of data\[$r\]"
  }