On 01/04/2018 01:25 PM, Pedro Alves wrote:
> On 01/04/2018 08:35 AM, Joel Brobecker wrote:
>> This patch adds a new testcase to demonstrate a regression introduced by:
>>
>>     commit b5ec771e60c1a0863e51eb491c85c674097e9e13
>>     Date:   Wed Nov 8 14:22:32 2017 +0000
>>     Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
>>
>> The purpose of the testcase is to verify that a user can use any
>> casing for an Ada symbol name passed to the "info address" command.
>> After the patch above was applied, GDB was no longer able to find
>> the symbol:
>>
>>     (gdb) info address My_Table
>>     No symbol "My_Table" in current context.
> 
> The mixed-case aspect is actually a red herring here.  Using
> lowercase doesn't work either:
> 
>  (gdb) info address my_table
>  No symbol "my_table" in current context.
> 
> I think the problem is instead that "info address" is doing a
> symbol_name_match_type::FULL match, but the symbol's full name
> is pck.my_table, which doesn't match.
> 
> If you pass the fully-qualified name, then it work, regardless
> of casing:
> 
>  (gdb) info address pck.My_Table
>  Symbol "pck.my_table" is static storage at address 0x6155e0.
> 
>  (gdb) info address pck.my_table
>  Symbol "pck.my_table" is static storage at address 0x6155e0.
> 
>  (gdb) info address Pck.My_Table
>  Symbol "pck.my_table" is static storage at address 0x6155e0.
> 
> Ada mode wants symbol names in expressions to be looked up
> using wild matching, unlike other languages.  To handle that
> I had added symbol_name_match_type::EXPRESSION:
> 
>   /* Expression matching.  The same as FULL matching in most
>      languages.  The same as WILD matching in Ada.  */
>   EXPRESSION,
> 
> IIRC, this is mainly used in the completion paths.
> 
> I think we'll need to make "info address" use it too, and
> possibly other commands that accept an expression as argument.
Turns out that the Ada symbol lookup machinery is sufficiently decoupled
from "regular" lookup that the problem is elsewhere.
While we may still want to consider migrating that hack towards
symbol_name_match_type::EXPRESSION, things should still work in
principle without doing that, AFAICT.

Whether to do a full or wild match is decided based on the lookup name
string (see name_match_type_from_name).  That was introduced basically
as a refactor of preexisting code, IIRC.

I traced the problem to the verbatim-wrapping hack in
ada_lookup_encoded_symbol.

See the attached patch.  It fixes gdb.ada/info_addr_mixed_case,
and introduces no regressions for me.  WDYT?