Re: [patch] STT_GNU_IFUNC support

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 17 Feb 2010 13:34:15 +0100, Pedro Alves wrote:
> On Monday 15 February 2010 18:40:50, Daniel Jacobowitz wrote:
> > Do you mean that "print strcmp" or "break strcmp" is now going to do
> > an inferior call?  That doesn't seem like a good idea to me.  I would
> > like for some other maintainers to comment though.
> > 
> > Inferior calls are very slow, and they can go wrong (pending signals,
> > misbehaving programs, etc).  I believe we should make an effort to
> > minimize them.
> 
> Yeah, agreed, we should avoid them the best we can.

Possibilities known to me:

(A) Call ifunc-resolver any time it is needed.
    = currently implemented.
(B) Pick out the resolver result from .got.plt - if it is already there;
    otherwise (A).
(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.

When an inferior call of "strcmp (...)" is being made I do not find a problem
doing also the ifunc-resolver call that time, do you?

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?


> [ Not to mention that the scheduler-locking setting also applies to
> them, meaning, in a multi-threaded environment, without more
> care, these behind the scenes infcalls resume more than
> you'd want (all-threads), which can be surprising, and make other
> threads easily hit events while handling the infcall.  Something
> that IWBN to fix. ]

If you are concerned about other threads running you should already use at
least "set scheduler-locking step".  It should be default anyway.

What about making this GNU-IFUNC inferior call scheduling follow the "step"
policy?  Maybe the whole inferior calls should follow the "step" policy?


Thanks,
Jan