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