Re: [patch, testsuite] require readline for gdb.linespec/explicit.exp tab-completion tests

[Sandra Loosemore <sandra at codesourcery dot com>]

On 09/17/2015 12:50 PM, Keith Seitz wrote:
> On 09/17/2015 12:28 AM, Sandra Loosemore wrote:
>
> > The immediate problem is that the response to the "break -function
> > mai\t" test doesn't always include the ^G character in the output
> > pattern, and the other FAILs are cascading off of the testcase not being
> > structured to recover from a pattern match failure (it's sending more
> > commands without a newline to terminate the one that failed).  But, I
> > have no clue why GDB is giving a ^G in some configurations and not
> > others (I observed that this test fails on nios2-elf target but passes
> > on nios2-linux-gnu, for instance), or whether this difference is
> > indicative of an actual bug.  So I've not touched that part of the
> > testcase.
>
> Can you reliably reproduce the failure? I have been unable to do so
> locally, but I have a couple of guesses why this test might fail.
>
> I've attached a patch where I've made two changes. First, I've switched
> from using "main" as a unique completion to some goofy new function
> where the name is hopefully truly unique.
>
> Second I believe the test is incorrect (or at least in combination with
> some readline versions?). ^G is output only for non-unique completions.
> So with this particular test, I don't think it should be present at all.
> I've removed it in the patch.
>
> If you can reliably reproduce the failure, I sure would love to know
> whether this patch helps at all.

Your patch makes these tests all PASS on both nios2-elf (where it 
formerly FAILed due to not beeping) and nios2-linux-gnu (where it used 
to beep and PASS).  I had come to pretty much the same conclusions -- I 
didn't think it was supposed to beep if there was a unique completion, 
and I thought there must be some sort of a duplicate symbol table entry 
for "main" on the Linux target coming from the startup code or something 
like that.  But it looks to me like the completer *is* finding a unique 
completion after beeping anyway.

So, while your patch does fix the FAILs, I'm wondering if there is a 
genuine code bug in the completer here; is it using different logic for 
deciding whether to beep than in what it does afterwards?  Personally, 
I'd feel uncomfortable changing the testcase to use something other than 
"main" without understanding why it beeps in some configurations and not 
others, because that might just be papering over the bug instead of 
fixing a bad testcase.

-Sandra