From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24428 invoked by alias); 17 Feb 2010 17:33:59 -0000 Received: (qmail 24409 invoked by uid 22791); 17 Feb 2010 17:33:57 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Feb 2010 17:33:51 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1HHXg99017470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Feb 2010 12:33:42 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1HHXdxX029504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 12:33:41 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o1HHXd05007309; Wed, 17 Feb 2010 18:33:39 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o1HHXcnM007308; Wed, 17 Feb 2010 18:33:38 +0100 Date: Wed, 17 Feb 2010 17:33:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Daniel Jacobowitz Subject: Re: [patch] STT_GNU_IFUNC support Message-ID: <20100217173338.GA32328@host0.dyn.jankratochvil.net> References: <20100214203512.GA838@host0.dyn.jankratochvil.net> <201002171234.15169.pedro@codesourcery.com> <20100217141912.GA28715@host0.dyn.jankratochvil.net> <201002171452.36043.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002171452.36043.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00428.txt.bz2 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 : 7d870: 83 3d a9 a9 2f 00 00 cmpl $0x0,0x2fa9a9(%rip) # 378220 <__cpu_features> 7d877: 75 05 jne 7d87e 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 = {} 0x3009a7d870 > > 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