Re: [patch] STT_GNU_IFUNC support

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 17 February 2010 14:19:12, Jan Kratochvil wrote:
> 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".
> 
> "Regular users" just print "strcmp (...)" and do not print "strcmp" which
> possibly makes (C) a viable option.

> +(CACHE) = + possibility: Cache the pointer in GDB.

Yes.  If possible, I'd pick C, maybe B -> C.  The thing that
ends up calling the resolver or strcmp_optimized_for_foo really
_is_ strcmp, no?  Isn't that what objdump/nm, etc. would show
as well for address of strcmp?  And B -> C is all that you'll be
able to do when debugging a core file.

> 
> 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?

Yes, they can be slow, but, the fact that random bad things can happen
that when you set the inferior running behind the scenes, is what
 troublesme the most.  It's really a last resort.

> > [ 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".  

Say I'm hard headed and I want scheduler locking off.  I'd still be
surprised when my threads get resumed when I do "b foo".

> It should be default anyway.

That's another story.

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

Or "on", should be the same.  But that's not enough, fully fixing
means removing breakpoints as well:  e.g., what if the user has
a breakpoint on (the ifunc-resolver of) "strcmp", or one of its
callees? -- "p strcmp" or "b strcmp" can stop working mysteriously
then, no?  Also, if ifunc-resolving takes locks internally, then
we _can't_ make that inferior call sched-locked --- we may
deadlock the inferior, and the infcall never ends.  Does
it (takes locks internally), or ever will?

-- 
Pedro Alves