[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140616063907.GX179@brightrain.aerifal.cx>
Date: Mon, 16 Jun 2014 02:39:08 -0400
From: Rich Felker <dalias@...c.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Mikael Pettersson <mikpelinux@...il.com>,
Russ Cox <rsc@...ang.org>,
Linux API <linux-api@...r.kernel.org>,
Ian Taylor <iant@...ang.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>
Subject: Re: [RFC 0/2] __vdso_findsym
On Sun, Jun 15, 2014 at 11:22:48AM -0700, Andy Lutomirski wrote:
> >>[1] The only comprehensible description of the GNU hash extension that
> >>I could find is on Oracle's blog (!)
> >>
> >
> > Curious about this blog. We do have a GNU hash implementation in Syslinux, too, for another reference.
> >
>
> https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections
>
> FWIW, I bet that __vdso_findsym could be smaller if it used the GNU
> hash. Maybe it would save about the same amount of space that turning
> on the GNU hash would take up.
How so? My implementation of gnu hash lookup in musl's dynamic linker
is somewhat larger than the sysv hash lookup, and that's even with
skipping the bloom filter (which did not seem to yield any benefit,
though we may revisit this issue later). The actual hash function is
_slightly_ smaller for gnu, but the lookup function has a lot more
work to do.
Of course for the size of vdso's symbol table, a pure linear search
with no hash table would suffice...
Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists