From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23644 invoked by alias); 17 Feb 2010 12:34:23 -0000 Received: (qmail 23635 invoked by uid 22791); 17 Feb 2010 12:34:23 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Feb 2010 12:34:19 +0000 Received: (qmail 23099 invoked from network); 17 Feb 2010 12:34:18 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Feb 2010 12:34:18 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] STT_GNU_IFUNC support Date: Wed, 17 Feb 2010 12:34:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: Daniel Jacobowitz , Jan Kratochvil References: <20100214203512.GA838@host0.dyn.jankratochvil.net> <20100215184048.GA16276@caradoc.them.org> In-Reply-To: <20100215184048.GA16276@caradoc.them.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002171234.15169.pedro@codesourcery.com> 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/msg00417.txt.bz2 On Monday 15 February 2010 18:40:50, Daniel Jacobowitz wrote: > On Sun, Feb 14, 2010 at 09:35:12PM +0100, Jan Kratochvil wrote: > > This implementation resolves ifunc in an uncached way by an inferior call any > > time the symbol resolution is needed. It does not try to pick out the jump > > address value from ".got.plt" as filled there by ld.so. (GDB stepping into > > library functions also does not try to do so.) > > 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. [ 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. ] -- Pedro Alves