This repository was archived by the owner on Nov 1, 2021. It is now read-only.
Fastcomp Backend won't compile. #2
Comments
|
Make sure you have emscripten-fastcomp-clang as your clang remote (this changed), and pull the latest incoming from there. See https://github.com/kripken/emscripten/wiki/LLVM-Backend |
|
I do and yes I did. |
|
That is my only guess, since that triple is defined in a header in both clang and llvm. Should work if you have the proper branch (incoming) in all 3 repos. Can you paste the output of |
|
Sure. On Tue, Mar 11, 2014 at 9:31 PM, Alon Zakai [email protected]:
|
|
(I don't see it pasted? Or were you going to paste it later?) |
|
I'm not at the computer I was attempting to build it on, i'll post it later. On Wed, Mar 12, 2014 at 10:53 AM, Alon Zakai [email protected]:
|
kripken
pushed a commit
that referenced
this issue
Jan 7, 2015
Due to what can only be described as a CRT bug, stdout and amazingly even stderr are not always flushed upon process termination, especially when the system is under high threading pressure. I have found two repros for this: 1) In lib\Support\Threading.cpp, change sys::Mutex to an std::recursive_mutex and run check-clang. Usually between 30 and 40 tests will fail. 2) Add OutputDebugStrings in code that runs during static initialization and static shutdown. This will sometimes generate similar failures. After a substantial amount of troubleshooting and debugging, I found that I could reproduce this from the command line without running check-clang. Simply make the mutex change described in #1, then manually run the following command many times by running it once, then pressing Up -> Enter very quickly: D:\src\llvm\build\vs2013\Debug\bin\c-index-test.EXE -cursor-at=D:\src\llvm\tools\clang\test\Index\targeted-preamble.h:2:15 D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -include D:\src\llvm\build\vs2013\tools\clang\test\Index\Output\targeted-cursor.c.tmp.h -Xclang -error-on-deserialized-decl=NestedVar1 -Xclang -error-on-deserialized-decl=TopVar | D:\src\llvm\build\vs2013\Debug\bin\FileCheck.EXE D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -check-prefix=PREAMBLE-CURSOR1 Sporadically they will fail, and attaching a debugger to a failed instance indicates that stdin of FileCheck.exe is empty. Note that due to the repro in #2, we can rule out a bug in the STL's mutex implementation, and instead conclude that this is a real flake in the windows test harness. Test Plan: Without patch: Ran check-clang 10 times and saw over 30 Unexpected failures on every run. With patch: Ran check-clang 10 times and saw 0 unexpected failures across all runs. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D4021 Patch by Zachary Turner! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210225 91177308-0d34-0410-b5e6-96231b3b80d8
kripken
pushed a commit
that referenced
this issue
Mar 13, 2015
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214619 91177308-0d34-0410-b5e6-96231b3b80d8
kripken
pushed a commit
that referenced
this issue
Nov 4, 2015
There was linker problem, and it turns out that it is not always safe to refer to vtable. If the vtable is used, then we can refer to it without any problem, but because we don't know when it will be used or not, we can only check if vtable is external or it is safe to to emit it speculativly (when class it doesn't have any inline virtual functions). It should be fixed in the future. http://reviews.llvm.org/D12385 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246214 91177308-0d34-0410-b5e6-96231b3b80d8
kripken
pushed a commit
that referenced
this issue
Jan 4, 2016
member function exists on a class. The previous trick depended on inheriting from the class it was checking, which will fail when I start marking things 'final'. Attempt #2: now with a special #ifdef branch for MSVC. Hopefully *this* actually builds with all supported compilers... git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256564 91177308-0d34-0410-b5e6-96231b3b80d8
kripken
pushed a commit
that referenced
this issue
Aug 9, 2016
…known to appease *-win32 targets. <stdin>:9:25: note: possible intended match here %call = tail call i8 @"\01?convert_char_rte@@$$J0YADD@Z"(i8 %x) #2 ^ git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273230 91177308-0d34-0410-b5e6-96231b3b80d8
juj
pushed a commit
that referenced
this issue
Jan 31, 2018
Summary: The test being added in this patch used to cause an assertion failure: /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp -- Exit Code: 134 Command Output (stderr): -- clang: /src/tools/clang/lib/AST/ASTDiagnostic.cpp:424: void clang::FormatASTNodeDiagnosticArgument(DiagnosticsEngine::ArgumentKind, intptr_t, llvm::StringRef, llvm::StringRef, ArrayRef<DiagnosticsEngine::ArgumentValue>, SmallVectorImpl<char> &, void *, ArrayRef<intptr_t>): Assertion `isa<NamedDecl>(DC) && "Expected a NamedDecl"' failed. #0 0x0000000001c7a1b4 PrintStackTraceSignalHandler(void*) (/build/./bin/clang+0x1c7a1b4) #1 0x0000000001c7a4e6 SignalHandler(int) (/build/./bin/clang+0x1c7a4e6) #2 0x00007f30880078d0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf8d0) #3 0x00007f3087054067 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35067) #4 0x00007f3087055448 abort (/lib/x86_64-linux-gnu/libc.so.6+0x36448) #5 0x00007f308704d266 (/lib/x86_64-linux-gnu/libc.so.6+0x2e266) #6 0x00007f308704d312 (/lib/x86_64-linux-gnu/libc.so.6+0x2e312) #7 0x00000000035b7f22 clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind, long, llvm::StringRef, llvm::StringRef, llvm::ArrayRef<std::pair<clang::DiagnosticsEngine::ArgumentKind, long> >, llvm::SmallVectorImpl<char>&, void*, llvm::ArrayRef<long>) (/build/ ./bin/clang+0x35b7f22) #8 0x0000000001ddbae4 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl<char>&) const (/build/./bin/clang+0x1ddbae4) #9 0x0000000001ddb323 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl<char>&) const (/build/./bin/clang+0x1ddb323) #10 0x00000000022878a4 clang::TextDiagnosticBuffer::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) (/build/./bin/clang+0x22878a4) #11 0x0000000001ddf387 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const (/build/./bin/clang+0x1ddf387) #12 0x0000000001dd9dea clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) (/build/./bin/clang+0x1dd9dea) #13 0x0000000002cad00c clang::Sema::EmitCurrentDiagnostic(unsigned int) (/build/./bin/clang+0x2cad00c) #14 0x0000000002d91cd2 clang::Sema::CheckShadow(clang::NamedDecl*, clang::NamedDecl*, clang::LookupResult const&) (/build/./bin/clang+0x2d91cd2) Stack dump: 0. Program arguments: /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp 1. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:214:23: current parser token ';' 2. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:213:26: parsing function body 'handleLinkageSpec' 3. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:213:26: in compound statement ('{}') /build/tools/clang/test/SemaCXX/Output/warn-shadow.cpp.script: line 1: 15595 Aborted (core dumped) /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp Reviewers: rsmith Reviewed By: rsmith Subscribers: krytarowski, cfe-commits Differential Revision: https://reviews.llvm.org/D33207 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303325 91177308-0d34-0410-b5e6-96231b3b80d8
kripken
pushed a commit
that referenced
this issue
May 25, 2018
------------------------------------------------------------------------ r323155 | chandlerc | 2018-01-22 23:05:25 +0100 (Mon, 22 Jan 2018) | 133 lines Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324068 91177308-0d34-0410-b5e6-96231b3b80d8
trippleflux
added a commit
to trippleflux/emscripten-fastcomp-clang
that referenced
this issue
Jun 4, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Errors with:
The text was updated successfully, but these errors were encountered: