[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Andreas Krebbel changed: What|Removed |Added CC||krebbel at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Andreas Krebbel --- Fixed per previous comment.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #19 from stli at linux dot ibm.com --- Fixed with gcc commit "S/390: Fix PR91628" https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=88e508f9f112acd07d0c49c53589160db8c85fcd If somebody is backporting this fix, please also backport gcc commit "S/390: Fix layout of struct sigaction_t" https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=434fe1a4092e12e5b518ef0716dc5b315e06118d Otherwise you'll still see tls testsuite FAILs.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #18 from Iain Buclaw --- (In reply to Iain Buclaw from comment #17) > I have no strong preferences, if people are wanting to go with the .S file, > then that's fine by me, feel free to commit (or I will if you'd prefer). > It would be better to prefix the name with double underscores, as it is an internal symbol to D runtime. CSYM(__ibmz_get_tls_offset):
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #17 from Iain Buclaw --- I have no strong preferences, if people are wanting to go with the .S file, then that's fine by me, feel free to commit (or I will if you'd prefer). I'm just noting that I've seen a patch to implement musl support on s390x. Looks like there'll be nothing conflicting though. https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01806.html
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #16 from Florian Weimer --- (In reply to rdapp from comment #15) > Any feedback on the two options I proposed? Is the .S file variant (I posted > last) ok? I'd prefer the patch from comment 13, but I'm not a GCC developer. You should post the patch to gcc-patches. I don't know enough about the architecture to review the CFI annotations for correctness, sorry.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #15 from rdapp at linux dot ibm.com --- Any feedback on the two options I proposed? Is the .S file variant (I posted last) ok?
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #14 from Carlos O'Donell --- My preference for would be a distinct *.S file as Florian suggests, it's the most robust solution. The only other alternative I would consider is a new __builtin_get_tls_offset() that does what you want, and then use the builtin. It complicates backporting but solves the problem for all runtimes that want access to a __tls_get_addr() equivalent for the architecture.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #13 from rdapp at linux dot ibm.com --- Created attachment 46859 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46859=edit __tls_get_offset in separate .S files As there were no further remarks as to which version is preferred (separate files or as before) I also prepared a patch using separate .S files. I included common/threadasm.s for "csym" but I guess threadasm should be named differently in the future.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #12 from Jakub Jelinek --- Though, looking at libdruntime, it already handles that and has several *.S files.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to Florian Weimer from comment #10) > (In reply to rdapp from comment #9) > > I opted for inline assembly to make sure r12 is not changed directly before > > the function call. Do you have an idea to guarantee this in another way? > > Wouldn't an out-of-line function in an .S file work? It's a bit annoying > because makefile changes will be needed, but maybe that's not too bad. > > Does D support top-level asm statements? Then perhaps you could use that to > define an out-of-line function. .S has the disadvantage that you need to take care about .note.GNU-stack etc. If D doesn't have toplevel asm, you could use toplevel asm in a C source perhaps.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #10 from Florian Weimer --- (In reply to rdapp from comment #9) > I opted for inline assembly to make sure r12 is not changed directly before > the function call. Do you have an idea to guarantee this in another way? Wouldn't an out-of-line function in an .S file work? It's a bit annoying because makefile changes will be needed, but maybe that's not too bad. Does D support top-level asm statements? Then perhaps you could use that to define an out-of-line function.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #9 from rdapp at linux dot ibm.com --- (In reply to Florian Weimer from comment #8) > Calling functions from inline assembly is always a bit iffy. For example, > your code lacks clobbers for the vector registers (if present) and the > condition code register. I don't know if s390/s390x has a red zone, or > specific call frame setup requirements (the psABI is ambiguous regarding the > latter for functions whose arguments all fit into registers, as it is the > case here). > > I would suggest not to use inline assembly for this purpose. Right about the missing registers. I was wary about building with an older GCC but the support only started with GCC9 so this should not be a problem. Apparently we can also add vector clobbers with -mno-vx. I opted for inline assembly to make sure r12 is not changed directly before the function call. Do you have an idea to guarantee this in another way?
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #8 from Florian Weimer --- (In reply to rdapp from comment #7) > Created attachment 46817 [details] > Proposed patch using __tls_get_offset > > I drafted a patch that uses __tls_get_offset instead of the internal symbol > following Florian's idea. > > Test suite looks similar to before. Is it OK? Calling functions from inline assembly is always a bit iffy. For example, your code lacks clobbers for the vector registers (if present) and the condition code register. I don't know if s390/s390x has a red zone, or specific call frame setup requirements (the psABI is ambiguous regarding the latter for functions whose arguments all fit into registers, as it is the case here). I would suggest not to use inline assembly for this purpose.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 rdapp at linux dot ibm.com changed: What|Removed |Added CC||rdapp at linux dot ibm.com --- Comment #7 from rdapp at linux dot ibm.com --- Created attachment 46817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46817=edit Proposed patch using __tls_get_offset I drafted a patch that uses __tls_get_offset instead of the internal symbol following Florian's idea. Test suite looks similar to before. Is it OK? Apart from that patch, however, I noticed that we FAIL in libphobos.allocations/tls_gc_integration.d libphobos.thread/tlsgc_sections.d but I'm not sure yet how serious that is.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #6 from Florian Weimer --- __tls_get_offset looks like this: __tls_get_offset: la %r2,0(%r2,%r12) jg __tls_get_addr The caller should be able to prepare for the la instruction, by subtracting r12 from r2. (Not sure whose r12 this, and if it's modified by the PLT code. If it is, things could get tricky.)
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #5 from Iain Buclaw --- (In reply to Florian Weimer from comment #4) > (In reply to Iain Buclaw from comment #3) > > The use of the function is for the garbage collector to be able to scan > > native TLS data. > > > > The logic of said function pretty much matches what the glibc macro > > __TLS_GET_ADDR is doing. > > But you can use __tls_get_addr on other architectures, right? > That is correct. I'll link the offending code for reference. http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/libdruntime/gcc/sections/elf_shared.d;h=7f9036bf5052861960f8a1d4a20838437c5c519c;hb=refs/heads/trunk#l1030 > I think for s390 and s390x, you should implement you own version of > __tls_get_addr (under a different/hidden name, of course) which is based on > __tls_get_offset, which is the official interface for this. Would it be possible to infer the base address of the TLS range doing that though?
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #4 from Florian Weimer --- (In reply to Iain Buclaw from comment #3) > The use of the function is for the garbage collector to be able to scan > native TLS data. > > The logic of said function pretty much matches what the glibc macro > __TLS_GET_ADDR is doing. But you can use __tls_get_addr on other architectures, right? I think for s390 and s390x, you should implement you own version of __tls_get_addr (under a different/hidden name, of course) which is based on __tls_get_offset, which is the official interface for this.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #3 from Iain Buclaw --- The use of the function is for the garbage collector to be able to scan native TLS data. The logic of said function pretty much matches what the glibc macro __TLS_GET_ADDR is doing.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- (In reply to Carlos O'Donell from comment #1) > Note that is also the case for Rust which uses > __pthread_get_minstack@@GLIBC_PRIVATE, and this has prevented us from doing > valid and meaningful cleanup of the libpthread internals to remove this > function. The use of __pthread_get_minstack@@GLIBC_PRIVATE in Rust was safe last time I checked, treating a missing function as indicating that glibc will not place the TCB on the stack. The use in OpenJDK follows this pattern too. If we change TCB allocation not to use the stack anymore, we can remove the function at the same time, and Rust and OpenJDK will still do the right thing. (This is just an aside here, of course.)
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #1 from Carlos O'Donell --- If the D runtime, or libphobos in particular, has a need to get a lower-level view of the TLS runtime then we should work together to formalize what's required and provide a low-level TLS ABI. Note that is also the case for Rust which uses __pthread_get_minstack@@GLIBC_PRIVATE, and this has prevented us from doing valid and meaningful cleanup of the libpthread internals to remove this function. The related glibc bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=16291 It would be great to get feedback on the required API and needs.
