Add support for native TLS on OS X#1461
Conversation
535a5c9 to
6f713b3
Compare
|
Added back emulate TLS for 32bit. |
src/rt/sections_osx.d
Outdated
There was a problem hiding this comment.
sorry if this is a nitpick..but couldn't you just use public import instead of a mixin?
There was a problem hiding this comment.
The reason I did it like this is because the code in sections_osxXX depends on code in sections_osx. I tried to avoid a circular dependency without changing too much of the code. Not sure if this is better though.
There was a problem hiding this comment.
I probably would have opted for creating a third/common file. The mixin approach has two problems: The mixin could change meaning depending on where it's used, and while editing the contents of the mixin, intellisense systems will not know where to look for the symbols. Newcomers looking at sections_osxXX may also be confused as well. I'm not sure how prevalent this type of thing is in the druntime code, but if it can be avoided, I think it should be.
There was a problem hiding this comment.
So you mean a fourth file? There's already section_osx.d, section_osx32.d and section_osx64.d.
I'll wait for some additional input before making any changes.
There was a problem hiding this comment.
Actually, taking a fresh look at things this morning, these three files are so short that I don't think it really makes sense to split them up. Can we just keep it all in one file?
There was a problem hiding this comment.
I guess that could work. I would still like some input form someone else as well.
There was a problem hiding this comment.
Ok, but I strongly believe that any of the solutions that I've suggested will have us in a better spot than a mixin.
There was a problem hiding this comment.
Actually, Looking at my code for shared libraries, I would have to change the SectionGroup struct and the onAddImage function as well. And per Walter's response in the forums, shared libraries should be made available for 64bit only. So this eliminates/differentiates most of what's still being shared between the two files sections_osx32.d and sections_osx64.d.
So could we go with my last suggestion, and have one file for each platform, and replace the imports in sections.d with this?
else version(OSX)
{
version(D_LP64)
public import rt.sections_osx64
else
public import rt.sections_osx32
}
There was a problem hiding this comment.
@bitwise-github I've updated the code now, structured according to your suggestion.
|
So, what's the deal with https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1918184&isPull=true |
6f713b3 to
53ef4ca
Compare
53ef4ca to
39cbac3
Compare
39cbac3 to
b56ff53
Compare
|
|
||
| void _d_dyld_getTLSRange(void* arbitraryTLSSymbol, void** start, size_t* size) { | ||
| dyld_enumerate_tlv_storage( | ||
| ^(enum dyld_tlv_states state, const dyld_tlv_info *info) { |
There was a problem hiding this comment.
Please don't use weird vendor extensions, for sure you can do it with a plain callback or a struct.
There was a problem hiding this comment.
The API is only offered using a blocks-based callback. The need to do that is in fact the only reason why the code exists in an extra .c file. I briefly considered reverse-engineering the Blocks ABI to use it from D, but just using it the way it is supposed to seems like the much easier and more robust solution.
b56ff53 to
5ab2402
Compare
5ab2402 to
37dca9c
Compare
|
New PR is: #1523 |
Runtime part of dlang/dmd#5346.