This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Fixing gdb.base/completion.exp (PR testsuite/12649)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Marek Polacek <mpolacek at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>
- Date: Mon, 2 May 2011 16:52:29 +0200
- Subject: Re: [RFC] Fixing gdb.base/completion.exp (PR testsuite/12649)
- References: <4DB82F26.30801@redhat.com> <201104281614.31962.pedro@codesourcery.com> <20110501091630.GA16372@host1.jankratochvil.net> <201105021519.25614.pedro@codesourcery.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