Re: [patch] STT_GNU_IFUNC support

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Wed, Feb 17, 2010 at 03:19:12PM +0100, Jan Kratochvil wrote:
> (C) Print just the bare ifunc-resolver address for "p strcmp".
> 
> +(CACHE) = + possibility: Cache the pointer in GDB.
> 
> "Regular users" just print "strcmp (...)" and do not print "strcmp" which
> possibly makes (C) a viable option.

I don't know.  What about "disassemble strcmp" - I think it should
disassemble the same thing that will show up in the assembly as "call
0x$hex <strcmp>".  But maybe automatically disassembling strcmp_sse is
more useful.

Hmm.  I guess that leaves "break strcmp" in a weird place since strcmp
will only be called once.  Maybe a breakpoint on an indirect function
should also set a breakpoint on the target of the indirect function?
This is slightly awkward to implement because there's no debug hook
after the indirect function returns; we'd have to do that
automatically to set the second breakpoint, or risk missing calls.

I'm open to suggestions.

> I would choose (A) + (CACHE) myself.  I did not find (CACHE) to be such
> a concern to implement it.  Inferior calls may be slow on embedded targets?

Inferior calls are hundreds of times slower than symbol lookups.  GDB
can do a lot of symbol lookups behind the scenes, for instance "info
func" will do a lookup_symbol for every function.  Since native x86_64
Linux inferior calls are only hundreds of times slower, you may not
notice this as much.  On a slower target, or a remote target, it may
be thousands of times slower.

-- 
Daniel Jacobowitz
CodeSourcery