Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
	Marek Polacek <mpolacek@redhat.com>,
	Joel Brobecker <brobecker@adacore.com>
Subject: Re: [RFC] Fixing gdb.base/completion.exp (PR testsuite/12649)
Date: Mon, 02 May 2011 15:30:00 -0000	[thread overview]
Message-ID: <201105021630.04082.pedro@codesourcery.com> (raw)
In-Reply-To: <20110502145229.GA22957@host1.jankratochvil.net>

On Monday 02 May 2011 15:52:29, Jan Kratochvil wrote:
> 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 ..."?

The "\t" method of completion interacts with readline, the
"complete command" method doesn't.  I think it's useful and
important to test the "\t" version, especially since it's
what CLI users are using.

As principle, I don't like rewriting to make a not understood
problem go away.  In this particular case, since it would be desirable
to keep at least one instance of the original form, we get to fix
at least that instance.  But when we know how to fix it, we can
fix all of the instances.  And then the original motivation to rewrite
using a different method disappears or at least diminishes.

> 
> 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.  Sounds like break1.c was added (2003) after the test was
originally written (199[89], and since the completion never worked as
intended by the author of test, always XFAILing, it was never
noticed break1.o was in the way.  I somehow not noticed the \",
making it so that my change wasn't enough anyway (needed yet one more
dot, or something better).  I'll remove it.

-- 
Pedro Alves


  reply	other threads:[~2011-05-02 15:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27 14:59 Marek Polacek
2011-04-27 15:05 ` Joel Brobecker
2011-04-27 15:13   ` Tom Tromey
2011-04-27 15:23   ` Pedro Alves
2011-04-27 17:41     ` Marek Polacek
2011-04-28 14:19       ` Pedro Alves
2011-04-28 15:14         ` Pedro Alves
2011-04-29 14:10           ` Marek Polacek
2011-05-02 14:58             ` Pedro Alves
2011-05-01  9:17           ` Jan Kratochvil
2011-05-02 14:00             ` Marek Polacek
2011-05-02 14:19             ` Pedro Alves
2011-05-02 14:53               ` Jan Kratochvil
2011-05-02 15:30                 ` Pedro Alves [this message]
2011-05-02 15:44                   ` Joel Brobecker
2011-05-02 15:50                     ` Pedro Alves
2011-05-02 15:56                   ` Jan Kratochvil
2011-05-02 16:10                     ` Pedro Alves
2011-05-02 16:35                       ` Jan Kratochvil
2011-05-02 16:54                         ` Pedro Alves
2011-05-02 17:04                           ` Jan Kratochvil
2011-05-02 17:21                             ` Jan Kratochvil
2011-05-02 17:23                             ` Pedro Alves
2011-05-02 17:29                               ` Jan Kratochvil
2011-05-02 17:53                                 ` Pedro Alves
2011-05-02 17:56                                   ` Pedro Alves
2011-05-05 15:11                 ` Tom Tromey
2011-04-28 11:56 ` Marek Polacek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201105021630.04082.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=mpolacek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox