This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]