]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/c-exp.y
Fix calling ifunc functions when resolver has debug info and different name
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:09 +0000 (13:04 +0100)
commita376e11d84ba7ea8cc7333c77043e20c7b0cfc91
treed28d8b4f0bc9dc7f75c76fc61dd75e110aab53be
parent02e169e2dac9b0354162eb0e7ee3fc95134b232d
Fix calling ifunc functions when resolver has debug info and different name

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:
2018-04-26  Pedro Alves  <palves@redhat.com>

* c-exp.y (variable production): Skip finding an alias for ifunc
symbols.
gdb/ChangeLog
gdb/c-exp.y