Re: [RFC] regresssion(internal-error) printing subprogram argument

[Pedro Alves <palves@redhat.com>]

Hi Joel,

I woke up realizing that I completely forgot that psymbols have no
overload/function parameter info in C++, so a straight strcmp probably
doesn't work properly for C++.  Indeed, I remembered now to do
"maint check-psymtabs" when debugging gdb, and I get back a few
problems:

(top-gdb) maint check-psymtabs 
Global symbol `__gnu_cxx::operator!=<symtab_and_line*, std::vector<symtab_and_line> >' only found in src/gdb/cli/cli-cmds.c psymtab
Global symbol `__gnu_cxx::operator-<const symtab_and_line*, std::vector<symtab_and_line> >' only found in src/gdb/cli/cli-cmds.c psymtab
[...]

Maybe what we need is to be a little less aggressive then and
add a new symbol_name_match_type::SEARCH_SYMBOL instead that takes as
input a non-user-input search symbol like symbol_name_match_type::LITERAL
was, and then we skip any decoding/demangling steps (like LITERAL) and make:
  - Ada treat that as a verbatim match,
  - other languages treat it as symbol_name_match_type::FULL.

I can't look at this right now, though I'll try to play with it a bit
more later today.  I'm a bit worried on timing since I'm going to be
away next week (today's my last official day before xmas holiday).  :-/

No idea offhand on the issue below.

Thanks,
Pedro Alves

On 12/15/2017 09:47 AM, Joel Brobecker wrote:
>> Reading back the patch on the list, I realized that this must be
>> fixing "maint check-psymtabs" for Ada.  And indeed, without my
>> patch, I get here:
>>
>> $ gdb ./testsuite/outputs/gdb.ada/var_arr_typedef/var_arr_typedef 
>> (gdb) start
>> ...
>> (gdb) maint check-psymtabs 
>> Global symbol `adaS' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> Global symbol `interfacesS' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> Global symbol `packB' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> Global symbol `packS' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> Global symbol `systemS' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> Global symbol `var_arr_typedefB' only found in gdb/testsuite/outputs/gdb.ada/var_arr_typedef/b~var_arr_typedef.adb psymtab
>> (gdb)
>>
>> After:
>>
>> (gdb) start
>> ...
>> (gdb) maint check-psymtabs 
>> (gdb
>>
>> Looks like we only test that command for C, currently...
> 
> Good point!
> 
> Here is a commit which adds a testcase.
> 
> Sadly, unlike you, I still get an error:
> 
>     (gdb) maintenance check-psymtabs
>     Global symbol `interfaces__cS' only found in /[...]/maint_with_ada/b~var_arr_typedef.adb psymtab
> 
> I am not sure why this is happening just yet; the symbol, at first,
> looked like it had an interesting feature, which is both a DW_AT_name
> and a DW_AT_linkage name:
> 
>     <1><ad2>: Abbrev Number: 35 (DW_TAG_variable)
>        <ad3>   DW_AT_name        : (indirect string, offset: 0x476): ada_main__u00047
>        <ad7>   DW_AT_decl_file   : 5
>        <ad8>   DW_AT_decl_line   : 132
>        <ad9>   DW_AT_linkage_name: (indirect string, offset: 0x1b7e): interfaces__cS
>        <add>   DW_AT_type        : <0x79>
>        <ae1>   DW_AT_external    : 1
>        <ae1>   DW_AT_location    : 9 byte block: 3 20 1 0 0 0 0 0 0        (DW_OP_addr: 120)
> 
> However, there are plenty of other similar symbols, for instance:
> 
>  <1><b04>: Abbrev Number: 35 (DW_TAG_variable)
>     <b05>   DW_AT_name        : (indirect string, offset: 0x4b9): ada_main__u00049
>     <b09>   DW_AT_decl_file   : 5
>     <b0a>   DW_AT_decl_line   : 136
>     <b0b>   DW_AT_linkage_name: (indirect string, offset: 0x17cc): system__bounded_stringsS
>     <b0f>   DW_AT_type        : <0x79>
>     <b13>   DW_AT_external    : 1
>     <b13>   DW_AT_location    : 9 byte block: 3 28 1 0 0 0 0 0 0        (DW_OP_addr: 128)
> 
> So I'm still not sure what makes interfaces__cS special. I will look
> into it when I have a chance...
>