Re: [PATCH v2 02/15] Fix calling ifunc functions when resolver has debug info and different name

[Simon Marchi <simark@simark.ca>]

On 2018-03-25 03:19 PM, Pedro Alves wrote:
> Currently, on Fedora 27 (glibc 2.26), if you try to call strlen in the
> inferior you get:
> 
>  (gdb) p strlen ("hello")
>  $1 = (size_t (*)(const char *)) 0x7ffff554aac0 <__strlen_avx2>
> 
> strlen is an ifunc function, and what we see above is the result of
> calling the ifunc resolver in the inferior.  That returns a pointer to
> the actual target function that implements strlen on my machine.  GDB
> should have turned around and called the resolver automatically
> without the user noticing.
> 
> This is was caused by commit:
> 
>   commit bf223d3e808e6fec9ee165d3d48beb74837796de
>   Date: Mon Aug 21 11:34:32 2017 +0100
> 
>       Handle function aliases better (PR gdb/19487, errno printing)
> 
> which added the find_function_alias_target call to c-exp.y, to try to
> find an alias with debug info for a minsym.  For ifunc symbols, that
> finds the ifunc's resolver if it has debug info (in the example it's
> called "strlen_ifunc"), with the result that GDB calls that as a
> regular function.
> 
> After this commit, we get now get:
> 
>   (top-gdb) p strlen ("hello")
>   '__strlen_avx2' has unknown return type; cast the call to its declared return type
> 
> Which is correct, because __strlen_avx2 is written in assembly.
> That'll be improved in a following patch, though.
> 
> gdb/ChangeLog:
> yyyy-mm-dd  Pedro Alves  <palves@redhat.com>
> 
> 	* c-exp.y (variable production): Skip finding an alias for ifunc
> 	symbols.
> ---
>  gdb/c-exp.y | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/c-exp.y b/gdb/c-exp.y
> index 8dc3c068a5e..e2ea07cd792 100644
> --- a/gdb/c-exp.y
> +++ b/gdb/c-exp.y
> @@ -1081,7 +1081,9 @@ variable:	name_not_typename
>  				 is important for example for "p
>  				 *__errno_location()".  */
>  			      symbol *alias_target
> -				= find_function_alias_target (msymbol);
> +				= (msymbol.minsym->type != mst_text_gnu_ifunc
> +				   ? find_function_alias_target (msymbol)
> +				   : NULL);
>  			      if (alias_target != NULL)
>  				{
>  				  write_exp_elt_opcode (pstate, OP_VAR_VALUE);
> 

Just one question, to which I really don't have a preconceived answer:

Would it make sense to add that filtering to find_function_alias_target or
another function deeper in the call chain instead?  In other words, would
it ever make sense for find_function_alias_target to return an non-NULL
result for an mst_text_gnu_ifunc minimal symbol?

Simon

Simon