This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] STT_GNU_IFUNC support
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