Is there a reason to use the hash table at all? There are fewer than a dozen symbols in the VDSO.

The format of DT_GNU_HASH is defined at https://sourceware.org/ml/binutils/2006-06/msg00418.html and probably other places as well.

I don't think that's the format that was settled on. It certainly doesn't match up with what's in the VDSO. This seems to be an up-to-date description: https://flapenguin.me/2017/05/10/elf-lookup-dt-gnu-hash/

It speeds up linking at some point but the vDSO, let's say on amd64, has only 4 functions so this perfomance tweak wold be minimal.

At the same time it's not easier to parse than the standard DT_HASH.

CL https://golang.org/cl/45511 mentions this issue.

Yes, sorry, by "at all" I didn't mean "why do these .so's have these pesky hash tables at all" :) I just meant why is Go bothering to implement hash table parsing when the only thing we use that code for is an object with only a handful of symbols?

We don't need the hash table to speed up lookups, we need the hash table because that is what the dynamic linker looks at. The dynamic linker does not fall back to searching the symbol table if there is no hash table, it just punts. I suggested that we add DT_GNU_HASH because I would not be surprised if at some point the GNU/Linux dynamic linker starts to require it.

Oh, wait, that was the wrong answer. Sorry. We need to recognize DT_GNU_HASH because the VDSO doesn't always have a symbol table. We used to just look through the symbol table, but that broke. Similarly I expect that at some point the VDSO will drop the DT_HASH table.

We need to recognize DT_GNU_HASH because the VDSO doesn't always have a symbol table.

Your point over on the CL pointed me in the right direction. If I understand correctly, it's not exactly that it "doesn't always have a symbol table" since even the hash tables have to index into something. It's that the only way to know the size of the dynamic symbol table is if there's a section for it, and there isn't always a section table. What I hadn't realized before was that the size was missing.