Support for clang++ and libcxx? about mcfgthread HOT 13 CLOSED

Worth trying.

from mcfgthread.

@FrankHB

make it happen? 😂

from mcfgthread.

If I had time...
-1s :(

from mcfgthread.

Does this project have any problems compiling with clang on windows?

And what the target is? mingw-w64? msvc?

from mcfgthread.

@CarterLi
There might be. I haven't tested it yet.

from mcfgthread.

See http://lists.llvm.org/pipermail/cfe-dev/2017-March/053339.html.

from mcfgthread.

https://gcc.godbolt.org can generate Intel-style ASM somehow
https://godbolt.org/g/MyraQx

from mcfgthread.

That is irrelevant. The problem is that at the moment _seh_top.h doesn't compile on clang for i686. On x64 there is no problem because the AT&T and Intel dialects happen to be the same.

from mcfgthread.

not sure but
__asm__ volatile (
"mov{l} {%%fs:0, %0|%0, dword ptr fs:[0]} \n"
"mov{l} {%0, (%1)|dword ptr[%1], %0} \n"
"mov{l} {%2, 4(%1)|dword ptr[%1 + 4], %2} \n"
"mov{l} {%1, %%fs:0|dword ptr fs:[0], %1} \n"
: "=&r"(__pUnused) : "r"(__pSehNode), "p"(__MCFCRT_SehTopDispatcher)
);
`
will generate the same code for at&t and Intel syntax?

from mcfgthread.

I suspect that's correct.

At the moment we have -masm=intel which should be removed first. PRs are welcome.

from mcfgthread.

Refactored so far. I am not sure whether clang people would show any interest on this project as they seem to prefer native TLS (using MSVC as the backend).

from mcfgthread.

will generate the same code for at&t and Intel syntax?

It seems there is no way to make clang accept Intel syntax, so I decide to stick to AT&T syntax, and leave Intel syntax in comments. This piece of assembly was actually created by disassembling GCC's output with GDB.

from mcfgthread.

This is the last error that is blocking Clang support: llvm/llvm-project#55329

from mcfgthread.