DynamicLinking.md: make it match llvm/emscripten

[yamt]

@sbc100 can you take a look? thank you.

[yamt]

I guess I never implemented immutable GOT.func globals. They seem to have been immutable from the very start: https://reviews.llvm.org/D54647

i see.

I do wonder if we can get some kind of perf win from making them immutable?

maybe. however, immutable GOT.func is actually not that simple to implement correctly, considering function pointer comparison and aliases.

[sbc100]

I guess I never implemented immutable GOT.func globals. They seem to have been immutable from the very start: https://reviews.llvm.org/D54647

i see.

I do wonder if we can get some kind of perf win from making them immutable?

maybe. however, immutable GOT.func is actually not that simple to implement correctly, considering function pointer comparison and aliases.

I'm not quite sure what you mean here. Both GOT.func and GOT.data globals are logically immutable, in that they never change once user code starts runnings. They are only mutable in order so that we can solve the mutual instantiation problem and will be set by the linker (once) before any user code runs.

The difference with GOT.func is that it holds table index. Since the table can be mutated during startup there is no need to also mutate the GOT.func global. i.e. we don 't need two levels of indirection here, and table-as-indirection should suffice.

[yamt]

I guess I never implemented immutable GOT.func globals. They seem to have been immutable from the very start: https://reviews.llvm.org/D54647

i see.

I do wonder if we can get some kind of perf win from making them immutable?

maybe. however, immutable GOT.func is actually not that simple to implement correctly, considering function pointer comparison and aliases.

I'm not quite sure what you mean here. Both GOT.func and GOT.data globals are logically immutable, in that they never change once user code starts runnings. They are only mutable in order so that we can solve the mutual instantiation problem and will be set by the linker (once) before any user code runs.

The difference with GOT.func is that it holds table index. Since the table can be mutated during startup there is no need to also mutate the GOT.func global. i.e. we don 't need two levels of indirection here, and table-as-indirection should suffice.

i meant that, to make function pointer comparison in C work as expected, we should use the same table index for the same function, regardless of how it's imported. maybe it can be done before instantiation as you say, but it's a bit complex to implement that way.

[sbc100]

I guess I never implemented immutable GOT.func globals. They seem to have been immutable from the very start: https://reviews.llvm.org/D54647

i see.

I do wonder if we can get some kind of perf win from making them immutable?

maybe. however, immutable GOT.func is actually not that simple to implement correctly, considering function pointer comparison and aliases.

I'm not quite sure what you mean here. Both GOT.func and GOT.data globals are logically immutable, in that they never change once user code starts runnings. They are only mutable in order so that we can solve the mutual instantiation problem and will be set by the linker (once) before any user code runs. The difference with GOT.func is that it holds table index. Since the table can be mutated during startup there is no need to also mutate the GOT.func global. i.e. we don 't need two levels of indirection here, and table-as-indirection should suffice.

i meant that, to make function pointer comparison in C work as expected, we should use the same table index for the same function, regardless of how it's imported. maybe it can be done before instantiation as you say, but it's a bit complex to implement that way.

Agreed, that table index should not change. That is kind of my point. The table indexes can be assigned up front, before we know which shared library actually defines a given symbol. Once we know where the symbol is defined we can do a table.set on the index that we already assigned.