From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1712 Path: news.gmane.org!not-for-mail From: musl Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso : dladdr support Date: Fri, 24 Aug 2012 09:29:29 +0200 Message-ID: <50372D59.7090604@gmail.com> References: <20120808115202.GL30810@port70.net> <5022703B.3090105@gmail.com> <20120811230536.GQ27715@brightrain.aerifal.cx> <20120817053934.GS27715@brightrain.aerifal.cx> <50311776.9040802@gmail.com> <20120820020626.GD27715@brightrain.aerifal.cx> <503233A8.8000604@gmail.com> <50324A60.7040206@gmail.com> <20120823213937.GS27715@brightrain.aerifal.cx> <20120823222113.GT27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1345793391 26579 80.91.229.3 (24 Aug 2012 07:29:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2012 07:29:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1713-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 24 09:29:52 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T4oL1-000388-Ps for gllmg-musl@plane.gmane.org; Fri, 24 Aug 2012 09:29:51 +0200 Original-Received: (qmail 22075 invoked by uid 550); 24 Aug 2012 07:29:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22059 invoked from network); 24 Aug 2012 07:29:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9UT0WyXMRCkyipXGFS/uN6JvhAC/x2WEz7hU+xw0LxE=; b=WhF+twxLiMCjURRUMtWV5P/kvkTEGcVID1mVveUUmKQutx6pbIUNzfOdS8cVO39dfk mMEjbEGEN4fQ1FtF0lHgzmo5b1nSjfVKi5xhY0AMf7+GyAKdTFlUxZAWXIRgvngjGGEk n6dBGKRefSt3l8pL9HPTTbJ0i8Ea3MHyrVvvZjIa3qHEDmoiDPts0q3E3mwiPXCoXlxy BchOfYAStqhxH1PoYVO39dEYlJTXhzUPs1hRtjOhLx3TuMsISGHBUGav/Ry3wCKgH29G KdapUemw86I20EAX3tAhhunh3DkPGbbaCpvPSYFyHf31smgkB7HhwR2wnra6vmboWqvb i7hA== User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: <20120823222113.GT27715@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1712 Archived-At: On 24/08/2012 00:21, Rich Felker wrote: > On Thu, Aug 23, 2012 at 05:39:37PM -0400, Rich Felker wrote: >> On Mon, Aug 20, 2012 at 04:32:00PM +0200, musl wrote: >>> I missed a bug in my previous patch : >>> in find_sym func precomptab was always set to sysv_precomp. >> It's still broken; h is being used in the comparisons even if h was >> not initialized, rather than using gh. I'm working on integrating the >> code right now. I'll either commit my version or reply with a patch >> here soon for review. > Here's my proposed patch for gnu hash support. I've left dladdr to be > committed separately. I handled the precomputed hashes by duplicating > the code in the two branches; this is _ugly_ but it's moderately > faster, and I really don't like the performance impact of these checks > to begin with, so I'd rather not make them even worse. > > Some other changes I've made since Boris's last version: > > - Prefer GNU hash if it's available. It's a lot faster even in single > runs, and should make even more difference when data-locality issues > come into play (resolving whole files rather than just a single > dlsym call). > > - Omit bloom filter checks. It's not clear if they're beneficial on > average in large programs, but for single lookups where the symbol > is present, they increase lookup time by about 8%. > > - Replace the over-complicated decode_vec2 with search_vec, since we > only need a single extended entry anyway. In any case, the big-O > performance of high-entry lookups will always be the same as this > linear search unless we use heavy data structures, so we might as > well just do it this super-simple way. > > Comments welcome. I'll hold off on committing for a while in case I > made any dumb mistakes. I tested it and it works well. My tests are based on small libs (with a small set of shared symbols). I mixed libs with gnu hash and sysv hash. Tried to resolve symbols via dlsym. Have you tested it on big libraries ? Do you want me to do some specific tests ? > Rich