search

flapenguin / flapenguin.me-comments

Comments for https://flapenguin.me/
0 stars 0 forks source link

/elf-dt-hash ELF: symbol lookup via DT_HASH #1

Open flapenguin opened 4 years ago

flapenguin commented 4 years ago

https://flapenguin.me/elf-dt-hash

flapenguin commented 4 years ago

Comments from Disqus:

Anton Bikineev Tuesday, April 25, 2017 4:24 PM Nice article and good practical introduction, thanks.

It's a shame that neither C Standard nor C++ defines default symbol visibility. Things get even worse when it comes to OS specific default policies. For example in Windows for symbol to become visible one should explicitly mark it with __declspec(public) whereas in Linux all symbols are visible by default (not taking -fvisibility=hidden into account). This substantially degrades load times, binary size and symbol lookup.

flapenguin Friday, April 28, 2017 4:22 PM Thanks for your comment. Symbol visibility is an interesting topic. I think the reason why standard lacks support of it is because it's the linker who needs to know about symbol visibility. Linker should be able to link your C, C++, Asm and Rust shared libraries. So it's not only about adding keyword for visibility in C/C++, but also about specifying how linker should work with it, which potentially leads to specifying object and shared library formats and their capabilities. And that's what committee is avoiding as hard as they can. Correct me if I'm wrong.

BTW, internal linkage is effectively the same thing as hidden symbols, so there's at least one standard way to specify symbol visibility: by using static functions. But that surely doesn't help if you have multiple object files.

Also, with gnu/llvm toolchains you can hide all symbols during linking by using version scripts: https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html

Rajkumar Ramasamy Tuesday, September 12, 2017 10:34 AM Firstly, thanks for explaining this with a great example. :)

I have been working through the example you have provided. While constructing the hash table, I am seeing the following.

elf_hash(pthread_mutex_lock) % nbucket = 0x0de6a18b % 4 = 3. But bucket[3] = 4, which is a collision, so I want to use chain. Since chain[4] is not used so far, wont chain[4] = 6, instead?

I see in the example you have mentioned chain[4] = 0. Can you clarify this?

I never answered this in Disqus, so: chain[4] is not unused, it has 0, which means "end of symbols single linked list for this bucket". Also ix in chain[ix] is the symbol index, so you can't really have different one for pthread_mutex_lock.

egovind Thursday, May 11, 2017 7:00 PM

Thanks for the writeup, For the 2nd example shouldn't

"symbols[0] ("isnan") == "getspen"? nope => chain continues at 5" be "symbols[1] ("isnan") .." ?

flapenguin Wednesday, May 24, 2017 11:25 AM You're right. Fixed that. Thank you for noticing.

windelbouwman commented 4 years ago

I checked my own implementation of the ELF hash, and the first 4 example hashes are correct, but the table is not correct:

elf_hash("isnan") != 0x070a484c

flapenguin commented 4 years ago

I checked my own implementation of the ELF hash, and the first 4 example hashes are correct, but the table is not correct:

Thank you for noticing! I've fixed it.

SecMeant commented 3 years ago

I think procedure for walking "getspen" is wrong. The comment says "chain continues at 5" but next line shows lookup in symbols[4], same goes with next step in chain - comment says we continue at 7 but lookup happens at symbols[8].