Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: support DT_GNU_HASH in GNU/Linux VDSO #19649

Closed
ianlancetaylor opened this issue Mar 21, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@ianlancetaylor
Copy link
Contributor

commented Mar 21, 2017

Currently we only recognize DT_HASH in runtime/vdso_linux_amd64.go. However, my understanding is that the VDSO would work fine (other than for Go) if it were generated with only the newer DT_GNU_HASH tag. For future proofing, we should recognize DT_GNU_HASH as well.

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

@ianlancetaylor ianlancetaylor added this to the Go1.9 milestone Mar 21, 2017

@ianlancetaylor ianlancetaylor self-assigned this Mar 21, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

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/

@amenzhinsky

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2017

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.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 13, 2017

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

@aclements

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

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?

@aclements aclements modified the milestones: Go1.10Early, Go1.9 Jun 13, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2017

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2017

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.

@aclements

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

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.

@bradfitz bradfitz modified the milestones: Go1.10Early, Go1.10 Jun 14, 2017

@gopherbot gopherbot closed this in 9065c3b Aug 13, 2017

@golang golang locked and limited conversation to collaborators Aug 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.