-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sycl/unified/documentation #3
Sycl/unified/documentation #3
Conversation
This will most likely need reformatted.
A lot of formatting and some corrections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great concrete information!
sycl/doc/XilinxFPGACompilation.md
Outdated
It's of note that the SDx 2018.3 install comes with several platforms that do | ||
not work with the SYCL compiler, i.e. the ZYNC family of boards. Instead, you'll | ||
have to use one of the newer boards, like the Alveo U250 (*xilinx_u250_xdma_201830_1*). | ||
This requires some additional installation steps for the moment as it doesn't come |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "for the moment"? Do you have some view about the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah no, I thought I removed that before pushing. I realized the wording made it sound like the platforms will eventually be included in the SDx install, but who knows if they ever will be.
sycl/doc/XilinxFPGACompilation.md
Outdated
|
||
How to: | ||
1. Download the Deployment and Development Shell for your OS from the [Alveo U250 getting started page](https://www.xilinx.com/products/boards-and-kits/alveo/u250.html#gettingStarted). **Note**: you can also install the release version of the XRT runtime from here if you would rather use this than build from source. | ||
2. 1. Install XRT if you haven't already: ``sudo apt install xrt_201830.2.1.1695_<OS>-xrt.deb`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Say here you assume a Debian/Ubuntu Linux, there are also some RHEL/CentOS packages, but otherwise you should just install XRT from GitHub instead.
sycl/doc/XilinxFPGACompilation.md
Outdated
packaged with the SDx download. | ||
|
||
How to: | ||
1. Download the Deployment and Development Shell for your OS from the [Alveo U250 getting started page](https://www.xilinx.com/products/boards-and-kits/alveo/u250.html#gettingStarted). **Note**: you can also install the release version of the XRT runtime from here if you would rather use this than build from source. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/from the/from for example the/
Cool. Thanks for the clarification. |
logging messages that are written the same, making it difficult to know for certain which code path was taken based on a logfile. Add some words to make each unique. Right now the ordering for finding a FullUnwindPlan (ignoring fallback unwind plan logic) is 1. If this is a _sigtramp like function, try eh_frame which is hand written on darwin systems to account for finding the saved register context correctly. 2. Ask the DynamicLoader if eh_frame should be preferred for this frame. Some binaries on the system may have hand-written eh_frame and the DynamicLoader is the source for this. (primarily this is for hand-written assembly in the objc runtime, and we tell lldb to trust that for functions in libobjc.dylib.) 3. if 0th frame, use GetUnwindPlanAtNonCallSite plan. 4. GetUnwindPlanAtCallSite {for 0th or any other} 5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.} 6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction 7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan I'm moving triSYCL#6 -- DefaultAtFunctionEntry -- up to between triSYCL#3 and triSYCL#4, where we're already doing things specific to the zeroth frame. If we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan has failed for some reason, and we're on the first instruction, we should definitely use DefaultAtFunctionEntry instead of any other unwind plan. If we're trying to step out of some rando function on the system that we couldn't assembly instruction inspect, this is sufficient for us to step out of it. llvm-svn: 359847
logging messages that are written the same, making it difficult to know for certain which code path was taken based on a logfile. Add some words to make each unique. Right now the ordering for finding a FullUnwindPlan (ignoring fallback unwind plan logic) is 1. If this is a _sigtramp like function, try eh_frame which is hand written on darwin systems to account for finding the saved register context correctly. 2. Ask the DynamicLoader if eh_frame should be preferred for this frame. Some binaries on the system may have hand-written eh_frame and the DynamicLoader is the source for this. (primarily this is for hand-written assembly in the objc runtime, and we tell lldb to trust that for functions in libobjc.dylib.) 3. if 0th frame, use GetUnwindPlanAtNonCallSite plan. 4. GetUnwindPlanAtCallSite {for 0th or any other} 5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.} 6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction 7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan I'm moving triSYCL#6 -- DefaultAtFunctionEntry -- up to between triSYCL#3 and triSYCL#4, where we're already doing things specific to the zeroth frame. If we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan has failed for some reason, and we're on the first instruction, we should definitely use DefaultAtFunctionEntry instead of any other unwind plan. If we're trying to step out of some rando function on the system that we couldn't assembly instruction inspect, this is sufficient for us to step out of it. llvm-svn: 359847
logging messages that are written the same, making it difficult to know for certain which code path was taken based on a logfile. Add some words to make each unique. Right now the ordering for finding a FullUnwindPlan (ignoring fallback unwind plan logic) is 1. If this is a _sigtramp like function, try eh_frame which is hand written on darwin systems to account for finding the saved register context correctly. 2. Ask the DynamicLoader if eh_frame should be preferred for this frame. Some binaries on the system may have hand-written eh_frame and the DynamicLoader is the source for this. (primarily this is for hand-written assembly in the objc runtime, and we tell lldb to trust that for functions in libobjc.dylib.) 3. if 0th frame, use GetUnwindPlanAtNonCallSite plan. 4. GetUnwindPlanAtCallSite {for 0th or any other} 5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.} 6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction 7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan I'm moving triSYCL#6 -- DefaultAtFunctionEntry -- up to between triSYCL#3 and triSYCL#4, where we're already doing things specific to the zeroth frame. If we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan has failed for some reason, and we're on the first instruction, we should definitely use DefaultAtFunctionEntry instead of any other unwind plan. If we're trying to step out of some rando function on the system that we couldn't assembly instruction inspect, this is sufficient for us to step out of it. llvm-svn: 359847
CONFLICT (content): Merge conflict in clang/test/Driver/clang-offload-wrapper.c
CONFLICT (content): Merge conflict in clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp CONFLICT (content): Merge conflict in clang/test/Driver/clang-offload-bundler.c
CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticSemaKinds.td
CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticSemaKinds.td
CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/Clang.cpp
…turn to external addr part) Before we have an issue with artificial LBR whose source is a return, recalling that "an internal code(A) can return to external address, then from the external address call a new internal code(B), making an artificial branch that looks like a return from A to B can confuse the unwinder". We just ignore the LBRs after this artificial LBR which can miss some samples. This change aims at fixing this by correctly unwinding them instead of ignoring them. List some typical scenarios covered by this change. 1) multiple sequential call back happen in external address, e.g. ``` [ext, call, foo] [foo, return, ext] [ext, call, bar] ``` Unwinder should avoid having foo return from bar. Wrong call stack is like [foo, bar] 2) the call stack before and after external call should be correctly unwinded. ``` {call stack1} {call stack2} [foo, call, ext] [ext, call, bar] [bar, return, ext] [ext, return, foo ] ``` call stack 1 should be the same to call stack2. Both shouldn't be truncated 3) call stack should be truncated after call into external code since we can't do inlining with external code. ``` [foo, call, ext] [ext, call, bar] [bar, call, baz] [baz, return, bar ] [bar, return, ext] ``` the call stack of code in baz should not include foo. ### Implementation: We leverage artificial frame to fix #2 and #3: when we got a return artificial LBR, push an extra artificial frame to the stack. when we pop frame, check if the parent is an artificial frame to pop(fix #2). Therefore, call/ return artificial LBR is just the same as regular LBR which can keep the call stack. While recording context on the trie, artificial frame is used as a tag indicating that we should truncate the call stack(fix #3). To differentiate #1 and #2, we leverage `getCallAddrFromFrameAddr`. Normally the target of the return should be the next inst of a call inst and `getCallAddrFromFrameAddr` will return the address of call inst. Otherwise, getCallAddrFromFrameAddr will return to 0 which is the case of #1. Reviewed By: hoy, wenlei Differential Revision: https://reviews.llvm.org/D115550
…he parser" This reverts commit b0e8667. ASAN/UBSAN bot is broken with this trace: [ RUN ] FlatAffineConstraintsTest.FindSampleTest llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15: runtime error: signed integer overflow: 1229996100002 * 809999700000 cannot be represented in type 'long' #0 0x7f63ace960e4 in mlir::ceilDiv(long, long) llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15 #1 0x7f63ace8587e in ceil llvm-project/mlir/include/mlir/Analysis/Presburger/Fraction.h:57:42 #2 0x7f63ace8587e in operator* llvm-project/llvm/include/llvm/ADT/STLExtras.h:347:42 #3 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> include/c++/v1/__memory/uninitialized_algorithms.h:36:62 #4 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> llvm-project/llvm/include/llvm/ADT/SmallVector.h:490:5 #5 0x7f63ace8587e in append<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, void> llvm-project/llvm/include/llvm/ADT/SmallVector.h:662:5 #6 0x7f63ace8587e in SmallVector<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long> > llvm-project/llvm/include/llvm/ADT/SmallVector.h:1204:11 #7 0x7f63ace8587e in mlir::FlatAffineConstraints::findIntegerSample() const llvm-project/mlir/lib/Analysis/AffineStructures.cpp:1171:27 #8 0x7f63ae95a84d in mlir::checkSample(bool, mlir::FlatAffineConstraints const&, mlir::TestFunction) llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:37:23 #9 0x7f63ae957545 in mlir::FlatAffineConstraintsTest_FindSampleTest_Test::TestBody() llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:222:3
…ified offset and its parents or children with spcified depth." This reverts commit a3b7cb0. symbol-offset.test fails under MSAN: [ 1] ; RUN: llvm-pdbutil yaml2pdb %p/Inputs/symbol-offset.yaml --pdb=%t.pdb [FAIL] llvm-pdbutil yaml2pdb <REDACTED>/llvm/test/tools/llvm-pdbutil/Inputs/symbol-offset.yaml --pdb=<REDACTED>/tmp/symbol-offset.test/symbol-offset.test.tmp.pdb ==9283==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55f975e5eb91 in __libcpp_tls_set <REDACTED>/include/c++/v1/__threading_support:428:12 #1 0x55f975e5eb91 in set_pointer <REDACTED>/include/c++/v1/thread:196:5 #2 0x55f975e5eb91 in void* std::__msan::__thread_proxy<std::__msan::tuple<std::__msan::unique_ptr<std::__msan::__thread_struct, std::__msan::default_delete<std::__msan::__thread_struct> >, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()> >(void*) <REDACTED>/include/c++/v1/thread:285:27 #3 0x7f74a1e55b54 in start_thread (<REDACTED>/libpthread.so.0+0xbb54) (BuildId: 64752de50ebd1a108f4b3f8d0d7e1a13) #4 0x7f74a1dc9f7e in clone (<REDACTED>/libc.so.6+0x13cf7e) (BuildId: 7cfed7708e5ab7fcb286b373de21ee76)
The asm parser had a notional distinction between parsing an operand (like "%foo" or "%4#3") and parsing a region argument (which isn't supposed to allow a result number like #3). Unfortunately the implementation has two problems: 1) It didn't actually check for the result number and reject it. parseRegionArgument and parseOperand were identical. 2) It had a lot of machinery built up around it that paralleled operand parsing. This also was functionally identical, but also had some subtle differences (e.g. the parseOptional stuff had a different result type). I thought about just removing all of this, but decided that the missing error checking was important, so I reimplemented it with a `allowResultNumber` flag on parseOperand. This keeps the codepaths unified and adds the missing error checks. Differential Revision: https://reviews.llvm.org/D124470
…ned form The DWARF spec says: Any debugging information entry representing the declaration of an object, module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and DW_AT_decl_column attributes, each of whose value is an unsigned integer ^^^^^^^^ constant. If however, a producer happens to emit DW_AT_decl_file / DW_AT_decl_line using a signed integer form, llvm-dwarfdump crashes, like so: (... snip ...) 0x000000b4: DW_TAG_structure_type DW_AT_name ("test_struct") DW_AT_byte_size (136) DW_AT_decl_file (llvm-dwarfdump: (... snip ...)/llvm/include/llvm/ADT/Optional.h:197: T& llvm::optional_detail::OptionalStorage<T, true>::getValue() & [with T = long unsigned int]: Assertion `hasVal' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/rocm/llvm/bin/llvm-dwarfdump ./testsuite/outputs/gdb.rocm/lane-pc-vega20/lane-pc-vega20-kernel.so #0 0x000055cc8e78315f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0 #1 0x000055cc8e780d3d SignalHandler(int) Signals.cpp:0:0 #2 0x00007f8f2cae8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #3 0x00007f8f2c58d00b raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #4 0x00007f8f2c56c859 abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:81:7 #5 0x00007f8f2c56c729 get_sysdep_segment_value /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:509:8 #6 0x00007f8f2c56c729 _nl_load_domain /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:970:34 #7 0x00007f8f2c57dfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6) #8 0x000055cc8e58ceb9 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2e0eb9) #9 0x000055cc8e58bec3 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2dfec3) #10 0x000055cc8e5b28a3 llvm::DWARFCompileUnit::dump(llvm::raw_ostream&, llvm::DIDumpOptions) (.part.21) DWARFCompileUnit.cpp:0:0 Likewise with DW_AT_call_file / DW_AT_call_line. The problem is that the code in llvm/lib/DebugInfo/DWARF/DWARFDie.cpp dumping these attributes assumes that FormValue.getAsUnsignedConstant() returns an armed optional. If in debug mode, we get an assertion line the above. If in release mode, and asserts are compiled out, then we proceed as if the optional had a value, running into undefined behavior, printing whatever random value. Fix this by checking whether the optional returned by FormValue.getAsUnsignedConstant() has a value, like done in other places. In addition, DWARFVerifier.cpp is validating DW_AT_call_file / DW_AT_decl_file, but not AT_call_line / DW_AT_decl_line. This commit fixes that too. The llvm-dwarfdump/X86/verify_file_encoding.yaml testcase is extended to cover these cases. Current llvm-dwarfdump crashes running the newly-extended test. "make check-llvm-tools-llvm-dwarfdump" shows no regressions, on x86-64 GNU/Linux. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D129392
Found by msan -fsanitize-memory-use-after-dtor. ==8259==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dbec54d2b8 in dtorRecord(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:150:22 #1 0x55dbec54bfcf in dtorArrayDesc(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:97:7 #2 0x55dbec508578 in invokeDtor clang/lib/AST/Interp/InterpBlock.h:79:7 #3 0x55dbec508578 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:55:19 #4 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #5 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #6 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22 #7 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #8 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #9 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40 #10 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7 #11 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38 #12 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7 #13 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27 #14 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3 #15 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8 #16 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11 #17 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25 #18 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15 #19 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12 #20 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12 #21 0x7f9be07fa632 in __libc_start_main #22 0x55dbe6a702e9 in _start Member fields were destroyed #0 0x55dbe6a7da5d in __sanitizer_dtor_callback_fields compiler-rt/lib/msan/msan_interceptors.cpp:949:5 #1 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:479:7 #2 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:612:3 #3 0x55dbec5094ac in llvm::SmallVector<clang::interp::Record::Base, 8u>::~SmallVector() llvm/include/llvm/ADT/SmallVector.h:1207:3 #4 0x55dbec508e79 in clang::interp::Record::~Record() clang/lib/AST/Interp/Record.h:24:7 #5 0x55dbec508612 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:49:26 #6 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #7 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #8 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22 #9 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #10 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #11 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40 #12 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7 #13 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38 #14 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7 #15 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27 #16 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3 #17 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8 #18 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11 #19 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25 #20 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15 #21 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12 #22 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12 #23 0x7f9be07fa632 in __libc_start_main #24 0x55dbe6a702e9 in _start
When building/testing ASan inside the GCC tree on Solaris while using GNU `ld` instead of Solaris `ld`, a large number of tests SEGVs on both sparc and x86 like this: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t> (a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at sanitizer_common/sanitizer_atomic_clang_x86.h:46 46 v = a->val_dont_use; 1: x/i $pc => 0xfe014cfc <_ZN11__sanitizer11atomic_loadINS_16atomic_uintptr_tEEENT_4TypeEPVKS2_NS_12memory_orderE+62>: mov (%eax),%eax (gdb) bt #0 0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t> (a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at sanitizer_common/sanitizer_atomic_clang_x86.h:46 #1 0xfe0bd1d7 in __sanitizer::DTLS_NextBlock (cur=0xfc602a58) at sanitizer_common/sanitizer_tls_get_addr.cpp:53 triSYCL#2 0xfe0bd319 in __sanitizer::DTLS_Find (id=1) at sanitizer_common/sanitizer_tls_get_addr.cpp:77 triSYCL#3 0xfe0bd466 in __sanitizer::DTLS_on_tls_get_addr (arg_void=0xfeffd068, res=0xfe602a18, static_tls_begin=0, static_tls_end=0) at sanitizer_common/sanitizer_tls_get_addr.cpp:116 triSYCL#4 0xfe063f81 in __interceptor___tls_get_addr (arg=0xfeffd068) at sanitizer_common/sanitizer_common_interceptors.inc:5501 triSYCL#5 0xfe0a3054 in __sanitizer::CollectStaticTlsBlocks (info=0xfeffd108, size=40, data=0xfeffd16c) at sanitizer_common/sanitizer_linux_libcdep.cpp:366 triSYCL#6 0xfe6ba9fa in dl_iterate_phdr () from /usr/lib/ld.so.1 triSYCL#7 0xfe0a3132 in __sanitizer::GetStaticTlsBoundary (addr=0xfe608020, size=0xfeffd244, align=0xfeffd1b0) at sanitizer_common/sanitizer_linux_libcdep.cpp:382 triSYCL#8 0xfe0a33f7 in __sanitizer::GetTls (addr=0xfe608020, size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:482 triSYCL#9 0xfe0a34b1 in __sanitizer::GetThreadStackAndTls (main=true, stk_addr=0xfe608010, stk_size=0xfeffd240, tls_addr=0xfe608020, tls_size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:565 The address being accessed is unmapped. However, even when the tests `PASS` with Solaris `ld`, `ASAN_OPTIONS=verbosity=2` shows ==6582==__tls_get_addr: Can't guess glibc version Given that that the code is stricly `glibc`-specific according to `sanitizer_tls_get_addr.h`, there seems little point in using the interceptor on non-`glibc` targets. That's what this patch does. Tested on `i386-pc-solaris2.11` and `sparc-sun-solaris2.11` inside the GCC tree. Differential Revision: https://reviews.llvm.org/D141385
Fix extensions/INTEL/SPV_INTEL_function_pointers/alias.ll for intel/llvm
Additional platform related documentation information for a board (Alveo U250) that has been tested to work with a release version of SDx 2018.3 on my machine. Replaces the old non-compiling zed platform. The documentation should be extendable to other boards for now.