Re: [RFC] Fixing gdb.base/completion.exp (PR testsuite/12649)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 02 May 2011 16:19:25 +0200, Pedro Alves wrote:
> On Sunday 01 May 2011 10:16:30, Jan Kratochvil wrote:
> > The "complete" command appraoch does introduce this new kind of race.
> > 
> > But the patch can be commited in two parts if it is preferred although
> > reviewing these racy send_gdb-gdb_expect cases for the intermediate step is
> > tricky and it gets dropped immediately afterwards.
> 
> What do you mean is dropped immediately afterwards?

Replacing this send_gdb + gdb_expect by gdb_test "complete ..." makes the GDB
codebase/testsuite more maintainable so I thought it could be changed now.

I found easier to replace the current constructs by gdb_test "complete ..." at
once although one can fix the gdb_expect first and delete it afterwards if you
wish.

Or are you against the replacement by gdb_test "complete ..."?

I have checked the code paths (despite what Tom says) and personally I cannot
imagine a difference between \t and the "complete" command.


> > > @@ -410,7 +365,7 @@ gdb_expect  {
> > >  		    timeout           {fail "(timeout) complete 'p \"break1.'"}
> > >  		}
> > >  	    }
> > > -	-re "^p \"break1\\..*$"
> > > +	-re "^p \"break1\\...*$"
> > >  	    {	send_gdb "\n"
> > >  		gdb_expect {
> > >  		    -re ".*$gdb_prompt $" { fail "complete 'p \"break1.'"}
> > 
> > I do not see this change as valid/relevant.
> 
> The pattern above reads:
> 
> 	-re "^p \"break1\\.c\"$"\
> ...
> 	-re "^p \"break1\\..*$"
> ...
> 
> It looked like "^p \"break1\\.c" could wrongly match the latter pattern,
> if the "c" wasn't in the buffer yet?

Aha.  But this testcase always FAILs (which it always considers as XFAIL)
because:
(1) gdb.base/break1.o prevents the completion (during in-tree build)
(2) GDB 7.3.50.20110502-cvs now completes it (with bundled readline) as:
	>p "break1.c < (note the trailing space)
    instead of expected
	>p "break1.c"<
    so it FAILs/XFAILs anyway.
So I am not sure what should be there when it cannot work anyway.


Thanks,
Jan