Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
D120048 decreases the number of lines and looks good to me. But for this one, there is now more complexity... Can we just let old systems (Solaris<=11.3) use *addr = 0; *size = 0;?
I don't care much about Solaris 11.3. While I do have patches to make LLVM work, I almost certainly won't submit them. However, even current day Illumos is the same, and just using D120048 will break the build for them due to the use of dlpi_tls_modid. Besides, we still have the matter of distinguishing Solaris and Illumos at build time. The current patch avoids all this.
Oh, thanks. Then perhaps adjust the code to work for Solaris 11.4 and let Illumos/Solaris 11.3 use the *addr = 0; *size = 0; fallback? That will have minimum code...
I hope we can get rid of main_tls_modid = 1; and rt_tlsmodid...
Oh, thanks. Then perhaps adjust the code to work for Solaris 11.4 and let Illumos/Solaris 11.3 use the *addr = 0; *size = 0; fallback? That will have minimum code...
That would effectively mean using D120048 amended to use some SANITIZER_ILLUMOS to distinguish the two. Currently, we don't have that unfortunately, as discussed in D119695. We'd also need to disable the ld -z relax=transtls workaround in that patch, but haven't a way to distinguish Solaris and Illumos in cmake files either.
I have an idea how to get __illumos__ defined (using uname -o in llvm/CMakeLists.txt) to handle the former, but in the end the Illumos community will have to come up with a solution that works for both Solaris and Illumos.
I hope we can get rid of main_tls_modid = 1; and rt_tlsmodid...
Fully agreed that's ugly, but at least it works for everyone and has been proven so in GCC. I'm certainly not vested in it, though, given that I primarily care about Solaris 11.4 where the common code just works.
Glad to know what you only care about Solaris>=11.4:)
It seems that D84046 is the first compiler-rt commit with llumos in the description. So I think compiler-rt has never officially supported illumnos.
Perhaps we should ask them to fix things before adding workarounds to compiler-rt?
Perhaps we can set up a milestone: they need to at least support __illumos__ and dlpi_tls_modid before adding the port to compiler-rt...
Glad to know what you only care about Solaris>=11.4:)
Sure: I'm keeping support in GCC since the 11.3/11.4 differences are useful in a couple of places and the effort is small. LLVM is different, though, given that Solaris support is only slowly coming.
It seems that D84046 is the first compiler-rt commit with llumos in the description. So I think compiler-rt has never officially supported illumnos.
Seems so: even the clang 13 in their oi-userland repo, which has some local patches, doesn't build compiler-rt.
Perhaps we should ask them to fix things before adding workarounds to compiler-rt?
Seems like a plan: instead of me constantly worrying about breaking the build for them without a sensible way for a workaround, the ball is in their court. I certainly don't intend to cause them problems and will continue to point out potential issues in my patches as far as I'm aware of them.
Perhaps we can set up a milestone: they need to at least support __illumos__ and dlpi_tls_modid before adding the port to compiler-rt...
Even the former would be enough as a first step: in that case, we can use the *addr = 0; *size = 0; fallback (though some sort of isOSIllumos() would be needed in clang to avoid using ld -z relax=transtls which they lack).
As a first step, I've filed Issue #53919 so what needs to be done can be kept in one place rather than spread over several reviews.
Abandoned unless absolutely necessary for Illumos support. As discussed, a way better alternative would be for them to implement dlpi_tls_modid or at least provide a way to distuingish Illumos from Solaris as outlined in Issue #53919.
Current compiler-rt was just integrated into GCC trunk, which broke the build on Solaris 11.3 for the lack of dlpi_tls_modid. S11.3 is still supported in GCC (and will remain so for quite some time), so I guess the best option forward is to reactivate this patch? @MaskRay?
As mentioned before, I'd like to revive this patch (although there's no Action in Phabricator for this AFAICS): importing upstream sanitizers into GCC libsanitizer broke the Solaris 11.3 build, which is still supported in GCC. As a side effect, it would also unbreak (at least in this regard) compiler-rt on Illumos.
Retested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11 (Solaris 11.4), and x86_64-pc-linux-gnu; as well as the same targets inside the GCC tree (also for Solaris 11.3 there).
compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp | ||
---|---|---|
361 | Instead of having two chunks of comments, just have one saying that the #if SANITIZER_SOLARIS branch is for Solaris < 11.4 compatibility? |
compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp | ||
---|---|---|
361 | That's way clearer indeed. |
clang-format: please reformat the code
36 diff lines are omitted. See full path.