Changes to support TLS access emitted in ILC (x64 win/linux) #429
Conversation
|
CC: @filipnavara |
| @@ -344,7 +344,7 @@ class MCObjectFileInfo { | |||
| } | |||
|
|
|||
| MCSection *getTLSExtraDataSection() const { return TLSExtraDataSection; } | |||
| const MCSection *getTLSDataSection() const { return TLSDataSection; } | |||
| MCSection *getTLSDataSection() const { return TLSDataSection; } | |||
There was a problem hiding this comment.
Why is this needed? Could we just mark things const on the objwriter side? Changes to LLVM outside of tools/objwriter need to be ported every time we update LLVM so there's a lot of value in keeping them as minimal as possible.
There was a problem hiding this comment.
Could we just mark things const on the objwriter side
I tried and propagating the const requires a lot of changes (const can be viral).
It is also inconsistent with the treatment other section accessors - i.e why getTLSDataSection is a const and getTLSBSSSection isn't?
I think the difference is unintentional. If we want const, we should make other sections accessors const as well.
There was a problem hiding this comment.
One possibility is to keep getTLSDataSection() as const (for no reason) and just cast the const away in the object writer.
There is a danger that something may eventually make dependency on this being const and it would not be easily noticeable when updating.
There was a problem hiding this comment.
cast the const away in the object writer
Such workaround stands out in the code and feels like a mildly dangerous hack.
I think we can do such change if removing the const becomes a burden when updating. It probably won't if upstream code does not change. It does not look like this part changes often.
There was a problem hiding this comment.
Just to be sure - I have noted the concern, but any way to deal with this issue has a downside. Removing the 'const' seems not distinctly worse than other solutions.
We need to pick one way to move forward while decision is not binding, since it is an implementation detail that can be changed. I am going to merge what we have, but will keep an eye if this becomes an issue.
|
Thanks!! |
|
@agocke - Is there something that need to be done to make this published/used by the runtime or it is automatic and just a matter of codeflow latency? |
|
It should just move forwards. I'll keep an eye out for the darc update |
|
Looks like flow is currently blocked on some unrelated changes: dotnet/runtime#87522 |
Changes to support TLS access emitted in ILC (x64 win/linux)
* Merge pull request dotnet#429 from VSadov/tls1 Changes to support TLS access emitted in ILC (x64 win/linux) * Fix DWARF debug information emitted for empty enum (dotnet#433) (cherry picked from commit 167a9c5) --------- Co-authored-by: Filip Navara <filip.navara@gmail.com>
These are companion changes for dotnet/runtime#87148
The change is for win-x64 and linux-x64 combinations as that is enough to discuss and test the parts of the runtime design that are not platform-specific.
More platform combinations can come as separate changes.