Re: [PATCH][gdb/symtab] Fix language of duplicate static minimal symbol

[Keith Seitz <keiths@redhat.com>]

On 10/30/18 12:11 PM, Tom de Vries wrote:
> However, when we use gdb to print info on foo, both foos are listed, but we
> get one symbol mangled and one symbol demangled:
> ...
> $ gdb ./a.out -batch -ex "info func foo"
> All functions matching regular expression "foo":
> 
> Non-debugging symbols:
> 0x00000000004004c7  foo()
> 0x00000000004004dd  _ZL3foov
> ...
> 

Good catch!

> Build and reg-tested on x86_64-linux.
> 
> OK for trunk?

I have just a few comments.

> 2018-10-30  Tom de Vries  <tdevries@suse.de>
> 
> 	* symtab.c (symbol_set_names): Call symbol_find_demangled_name
> 	unconditionally, to get the language of the symbol.

s/get/set/ ? When reading the patch, I originally wondered how that would help,
but symbol_find_demangled_name actually *sets* the gsymbol's language if
it is language_auto.

> 
> 	* gdb.base/msym.c: New test.
> 	* gdb.base/msym.exp: New file.
> 	* gdb.base/msym_main.c: New test.

These entries should be listed under the testsuite ChangeLog, like:

testsuite/ChangeLog:
YYYY-MM-DD ....

	* gdb.xyz/file1.c: ...
	* gdb.xyz/file1.exp: ....

[https://sourceware.org/gdb/wiki/ContributionChecklist#Properly_Formatted_GNU_ChangeLog]

"msym.c" et al aren't particularly descriptive, though. Can we devise a better,
more explicit name? Something along the lines of "multiple-language-msyms.exp".
It's long, but it describes things better. [I'm not saying you should use
this name, but something other than just "msym.{c,exp}".]

Sorry, some of that is kinda nitpicky.

> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index cd27a75e8c..481428f733 100644
> --- a/gdb/symtab.c
> +++ b/gdb/symtab.c
> @@ -818,6 +818,10 @@ symbol_set_names (struct general_symbol_info *gsymbol,
>    else
>      linkage_name_copy = linkage_name;
>  
> +  /* Set the symbol language.  */
> +  char *demangled_name = symbol_find_demangled_name (gsymbol,
> +						     linkage_name_copy);
> +
>    entry.mangled = linkage_name_copy;
>    slot = ((struct demangled_name_entry **)
>  	  htab_find_slot (per_bfd->demangled_names_hash,

symbol_find_demangled_name returns a malloc'd string which will leak here unless
the code goes through the branch. You'll need to save the result into a
unique_xmalloc_ptr and adjust the code accordingly.

Otherwise, LGTM. Thanks very much for the patch.

Keith (IANAM*)

* I am not a maintainer, you'll need to await final review by a global maintainer.