Calling ifunc functions when target has no debug info but resolver has
authorPedro Alves <palves@redhat.com>
Thu, 26 Apr 2018 12:01:26 +0000 (13:01 +0100)
committerPedro Alves <palves@redhat.com>
Thu, 26 Apr 2018 12:04:48 +0000 (13:04 +0100)
commit8388016d7ff8b88d29f2427963f26a6b8bbb03b1
tree5610897f1560b44237b0c05d56f6173f4c0c35d0
parenta376e11d84ba7ea8cc7333c77043e20c7b0cfc91
Calling ifunc functions when target has no debug info but resolver has

After the previous patch, on Fedora 27 (glibc 2.26), if you try
calling strlen in the inferior, you now get:

  (top-gdb) p strlen ("hello")
  '__strlen_avx2' has unknown return type; cast the call to its declared return type

This is correct, because __strlen_avx2 is written in assembly.

We can improve on this though -- if the final ifunc resolved/target
function has no debug info, but the ifunc _resolver_ does have debug
info, we can try extracting the final function's type from the type
that the resolver returns.  E.g.,:

  typedef size_t (*strlen_t) (const char*);

  size_t my_strlen (const char *) { /* some implementation */ }
  strlen_t strlen_resolver (unsigned long hwcap) { return my_strlen; }

  extern size_t strlen (const char *s);
  __typeof (strlen) strlen __attribute__ ((ifunc ("strlen_resolver")));

In the strlen example above, the resolver returns strlen_t, which is a
typedef for pointer to a function that returns size_t.  "strlen_t" is
the type of both the user-visible "strlen", and of the the target
function that implements it.

This patch teaches GDB to extract that type.

This is done for actual inferior function calls (in infcall.c), and
for ptype (in eval_call).  By the time we get to either of these
places, we've already lost the original symbol/minsym, and only have
values and types to work with.  Hence the changes to c-exp.y and
evaluate_var_msym_value, to ensure that we propagate the ifunc
minsymbol's info.

The change to make ifunc symbols have no/unknown return type exposes a
latent problem -- gdb.compile/compile-ifunc.exp calls a no-debug-info
function, but we did not warn about it.  The test is fixed by this
commit too.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

* blockframe.c (find_gnu_ifunc_target_type): New function.
(find_function_type): New.
* eval.c (evaluate_var_msym_value): For GNU ifunc types, always
return a value with a memory address.
(eval_call): For calls to GNU ifunc functions, try to find the
type of the target function from the type that the resolver
returns.
* gdbtypes.c (objfile_type): Don't install a return type for ifunc
symbols.
* infcall.c (find_function_return_type): Delete.
(find_function_addr): Add 'function_type' parameter.  For calls to
GNU ifunc functions, try to find the type of the target function
from the type that the resolver returns, and return it via
FUNCTION_TYPE.
(call_function_by_hand_dummy): Adjust to use the function type
returned by find_function_addr.
(find_function_addr): Add 'function_type' parameter and move
description here.
* symtab.h (find_function_type, find_gnu_ifunc_target_type): New
declarations.

gdb/testsuite/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

* gdb.compile/compile-ifunc.exp: Also expect "function has unknown
return type" warnings.
gdb/ChangeLog
gdb/blockframe.c
gdb/eval.c
gdb/gdbtypes.c
gdb/infcall.c
gdb/infcall.h
gdb/symtab.h
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.compile/compile-ifunc.exp