This is the mail archive of the
mailing list for the GDB project.
Re: [patch, testsuite] require readline for gdb.linespec/explicit.exp tab-completion tests
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 17 Sep 2015 15:09:12 -0600
- Subject: Re: [patch, testsuite] require readline for gdb.linespec/explicit.exp tab-completion tests
- Authentication-results: sourceware.org; auth=none
- References: <55FA6B97 dot 4080209 at codesourcery dot com> <55FB0B6C dot 6010401 at redhat 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
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.