Conversation
Previously, we were just hardcoding the assumption that the TLS block for the main binary starts 16 bytes after the thread control block. This is _usually_ true, but not always, so let's follow the spec more carefully by actually chasing the required pointers to get the correct address.
|
The demo in https://github.com/umanwizard/materialize-1/tree/test-custom-labels doesn't work without this change. |
|
Can we include a test for this and include a link to the “spec” in the code as well? |
|
@gnurizen we do already have a test for native custom labels in customlabels_test.go , so as long as that is still working I think this is okay. It's hard to write a test that would specifically fail due to this bug (i.e., that wouldn't have passed before this PR) because I haven't figured out exactly what causes the TLS block to not be located 16 bytes after the beginning of the thread control block. It seems to only happen in certain large programs (the only one I reproduced it in was Materialize's |
2 participants
Previously, we were just hardcoding the assumption that the TLS block for the main binary starts 16 bytes after the thread control block.
This is usually true, but not always, so let's follow the spec more carefully by actually chasing the required pointers to get the correct address.