Re: [PATCH,v2] Fix gdb.linespec/explicit.exp

[Luis Machado <lgustavo at codesourcery dot com>]

On 02/07/2017 05:59 AM, Pedro Alves wrote:
> On 01/31/2017 01:54 PM, Luis Machado wrote:
>
> > The first one is that i couldn't see the hex character x07 being ouput in both
> > of the above systems for this particular test. There is really only one
> > possible completion result for the main function. Maybe this character is
> > output in other systems?
>
> Yes.  Readline outputs the bell character (x07) when there's more than
> one possible completion.

Ah, that's what it is! I need to install my PC speaker for complete 
support. :-)

> I actually tripped on this a couple months back, while working on
> my palves/cp-linespec branch (on my github, it reworks completion support
> and adds a real linespec completer).  I have a fix there that says:
>
> ~~~
>     On the explicit.exp change:
>
>     The test currently expects a bell because:
>
>       (gdb) complete b -function main
>       b -function main
>       b -function main_arena
>
>     "main_arena" is a data global part of glibc's malloc implementation.
>     I.e., the test must be failing on target whose malloc implementation
>     doesn't share an ancestry with glibc's...
> ~~~
>
> So if you're on a glibc system with debug info for glibc, you'll
> see the bell.  Elsewhere, you won't.

Interesting! I have newlib in my case.

> gdb_test_multiple is just a wrapper around expect.  Not writing
> "-re" just means you're matching a pattern literally, instead of with
> a regex.  So without the -re, regexp things like ? or * have no
> special meaning, they are matched literally.
>
> See the manual at <http://www.tcl.tk/man/expect5.31/expect.1.html>,
> after "For example, the following fragment looks".
>
> > 	Make the x07 character optional in the unique function name completion
> > 	test.

Thanks for the info. I've kept the change to add the -re switches in the 
hopes people will not waste time trying to figure out what's up with 
their regular expressions that are not matching.

> This test is exercising completion of a _unique_ function name, so
> expecting a bell never really made sense...  A better fix would be to
> try completion of a symbol name that is more likely to not conflict
> with some other system symbol, like Keith was suggesting.

I've decided to add a new function that is, hopefully, more unique.

> Meanwhile, this is OK (with the commit log adjusted / clarified).

Thanks. Updated v3 will have this.