https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #15 from Stas Sergeev <stsp at users dot sourceforge.net> --- (In reply to Andrew Pinski from comment #13) > Those all have pure assembly code to handle this case. No, they actually simply don't use TLS in a handler. That's something I'll be looking into too to save me from all that pain, but its not like they write a part of sighandler in asm and do the syscalls in asm. > That is they have > wrapper code which handles the first part in pure C Guess you meant "pure asm" here. > and then pass it on to > the other code. If you have such an evidence - the URL would be nice. >From what I see they avoid the troubles simply by not using TLS. > I don't see why you need to do the first part in assembly code and then pass > it on to C code. Do you suggest syscalls in asm? int80h? sysenter? > Or why do you need to use the fs segment when it is part of the x86 Linux > ABI? It seems like you are outside of C/ABI at this stage and need pure > assembly to fix up your code. Again this is outside of the x86 Linux ABI > and GCC should not handle this at all. gcc handles many many things that are outside the ABI imho. It has many function attributes for all the weird cases... except this one of course. :) > Yes because you are setting the TLS segment. Again why are you abusing > the fs segment here not to be the TLS segment? IMHO linux itself should have been restoring FS. It doesn't, and as such, the signal handlers are violating the ABI. gcc can kindly fulfill the gap with just a small patch, as clang did, or even just by telling me the magic -mno-xxx option, or force the users to suffer.
