[v2] Fix gdb.linespec/explicit.exp

  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.

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.

The real problem is that the completer for linespecs should not be
finding "main_arena", because that's a data symbol, not a function.

The change to the test itself in the branch is:


> 
> So i started playing around with the regular expression to make x07 optional,
> but no matter what pattern i used, it just didn't match.
> 
> It was then that i noticed we're missing a leading "-re" before the
> gdb_test_multiple pattern to be matched, the second problem. I checked the
> documentation for the command and did not find anything about the use
> without "-re". So i assumed it is an oversight.

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.

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.

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

Thanks,
Pedro Alves
  

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.