Re: [patch] STT_GNU_IFUNC support

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

On Wed, 17 Feb 2010 15:52:36 +0100, Pedro Alves wrote:
> On Wednesday 17 February 2010 14:19:12, Jan Kratochvil wrote:
> > (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.


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

Yes, the gnu-ifunc resolver is called "strcmp":
nm:
000000303a87d8b0 t __strcmp_sse2
000000303a91c5e0 t __strcmp_sse42
000000303a923800 t __strcmp_ssse3
000000303a87d870 i strcmp
objdump -d:
000000000007d870 <strcmp>:
   7d870:       83 3d a9 a9 2f 00 00    cmpl   $0x0,0x2fa9a9(%rip)        # 378220 <__cpu_features>
   7d877:       75 05                   jne    7d87e <strcmp+0xe>
   7d879:       e8 e2 15 fa ff          callq  1ee60 <__init_cpu_features>


I was considering gdb as a more high-level tool than nm/objdump.

Anyway I find it now OK to resolve ifunc just for "strcmp()" (and not for
"strcmp").


> Yes.  If possible, I'd pick C, maybe B -> C.

(B): The .got.plt picker could be based on OSABI-dependent check of .rela.plt
type (such as is R_X86_64_JUMP_SLOT).

Do you consider it still worth it if the uncached gnu-ifunc resolver call
would be made only for real "strcmp()" inferior calls?


------------------------------------------------------------------------------

With the (C) "unresolving" option these items have became offtopic:


> And B -> C is all that you'll be > able to do when debugging a core file.

True.

Program terminated with signal 11, Segmentation fault.
(gdb) p strcmp
$1 = {<text gnu-ifunc variable, no debug info>} 0x3009a7d870 <strcmp>


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

Not so.  I find "step" to be the reasonable default (and it has been so for
a long time before me in RHEL/Fedora) and I find GNU-IFUNC resolving with
locked scheduler also as a reasonable default.  I do not find
"scheduler-locking on" as a reasonable GDB default.


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

It will stop at that breakpoint, I would find it valid.


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

gnu-ifunc is a general framework, it would be probably OK for a specific
application to take a lock during its gnu-ifunc resolver.

Quick scan of current ifunc resolvers in glibc does not show any locks.
Filed glibc/11292 about it, there seems to be a race.

Still such lock can be non-nesting and already taken by the current thread.
"scheduler-locking off" cannot always help.


Thanks,
Jan