Fix a compilation error on gcc8 #4
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The llvm project is not accepting github pull requests at this time. Please submit your patch at reviews.llvm.org. |
llvm-git-migration
pushed a commit
that referenced
this pull request
Feb 27, 2019
Currently, the LLVM will print an error like
Unsupported relocation: try to compile with -O2 or above,
or check your static variable usage
if user defines more than one static variables in a single
ELF section (e.g., .bss or .data).
There is ongoing effort to support static and global
variables in libbpf and kernel. This patch removed the
assertion so user programs with static variables won't
fail compilation.
The static variable in-section offset is written to
the "imm" field of the corresponding to-be-relocated
bpf instruction. Below is an example to show how the
application (e.g., libbpf) can relate variable to relocations.
-bash-4.4$ cat g1.c
static volatile long a = 2;
static volatile int b = 3;
int test() { return a + b; }
-bash-4.4$ clang -target bpf -O2 -c g1.c
-bash-4.4$ llvm-readelf -r g1.o
Relocation section '.rel.text' at offset 0x158 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name
0000000000000000 0000000400000001 R_BPF_64_64 0000000000000000 .data
0000000000000018 0000000400000001 R_BPF_64_64 0000000000000000 .data
-bash-4.4$ llvm-readelf -s g1.o
Symbol table '.symtab' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS g1.c
2: 0000000000000000 8 OBJECT LOCAL DEFAULT 4 a
3: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 b
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 64 FUNC GLOBAL DEFAULT 2 test
-bash-4.4$ llvm-objdump -d g1.o
g1.o: file format ELF64-BPF
Disassembly of section .text:
0000000000000000 test:
0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
2: 79 11 00 00 00 00 00 00 r1 = *(u64 *)(r1 + 0)
3: 18 02 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r2 = 8 ll
5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0)
6: 0f 10 00 00 00 00 00 00 r0 += r1
7: 95 00 00 00 00 00 00 00 exit
-bash-4.4$
. from symbol table, static variable "a" is in section #4, offset 0.
. from symbol table, static variable "b" is in section #4, offset 8.
. the first relocation is against symbol #4:
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
and in-section offset 0 (see llvm-objdump result)
. the second relocation is against symbol #4:
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
and in-section offset 8 (see llvm-objdump result)
. therefore, the first relocation is for variable "a", and
the second relocation is for variable "b".
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 354954
llvm-git-migration
pushed a commit
that referenced
this pull request
Mar 7, 2019
Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots:
```
=================================================================
==2453==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
#1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19
#2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12
#3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
#4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
#5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
#6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
#7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
#8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
#9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
#10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
#11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
#12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
#13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
#1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29
#2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241
#3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16
#4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
#5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
#6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
#7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
#8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
#9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
#10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
#11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
#12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
#13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
#14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s).
```
See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information.
Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr:
```
==7070==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5
#1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44
#2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78
#3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9
#4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314
#5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18
#6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
#7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
#8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
#9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
#10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
#11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
#12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
#13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
#14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
#15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User
```
See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information.
llvm-svn: 355616
cuviper
added a commit
to cuviper/llvm-project
that referenced
this pull request
Mar 18, 2019
[rust-lldb] Adapt to changes in LLDB APIs
llvm-git-migration
pushed a commit
that referenced
this pull request
Apr 8, 2019
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
llvm-svn: 357915
llvm-git-migration
pushed a commit
that referenced
this pull request
Apr 8, 2019
…heck.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
........
Breaks windows buildbots
llvm-svn: 357918
llvm-git-migration
pushed a commit
that referenced
this pull request
Apr 8, 2019
Re-commit r357915 with a fix for windows.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
llvm-svn: 357921
llvm-git-migration
pushed a commit
that referenced
this pull request
May 2, 2019
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 #6 -- DefaultAtFunctionEntry -- up to between #3 and #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
llvm-git-migration
pushed a commit
that referenced
this pull request
May 14, 2019
The code is currently using the ambiguous instruction "sub sp, sp, w9, lsl #4". The ARM reference manual says this isn't valid, and it's not clear whether it's supposed to mean uxtw or uxtx. It doesn't matter which instruction we use here, since the high bits of the operand are zero anyway, so I arbitrarily choose uxtw, to preserve the register name. See https://reviews.llvm.org/D60840 for the LLVM patch. Differential Revision: https://reviews.llvm.org/D61770 llvm-svn: 360711
llvm-git-migration
pushed a commit
that referenced
this pull request
Jun 11, 2019
Looks like a MachinePipeliner algorithm problem found by
sanitizer-x86_64-linux-fast.
I will backout this test first while investigating the problem to
unblock buildbot.
==49637==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x614000002e08 at pc 0x000004364350 bp 0x7ffe228a3bd0 sp 0x7ffe228a3bc8
READ of size 4 at 0x614000002e08 thread T0
#0 0x436434f in
llvm::SwingSchedulerDAG::checkValidNodeOrder(llvm::SmallVector<llvm::NodeSet,
8u> const&) const
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:3736:11
#1 0x4342cd0 in llvm::SwingSchedulerDAG::schedule()
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:486:3
#2 0x434042d in
llvm::MachinePipeliner::swingModuloScheduler(llvm::MachineLoop&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:385:7
#3 0x433eb90 in
llvm::MachinePipeliner::runOnMachineFunction(llvm::MachineFunction&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:207:5
#4 0x428b7ea in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:13
#5 0x4d1a913 in llvm::FPPassManager::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1648:27
#6 0x4d1b192 in llvm::FPPassManager::runOnModule(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1685:16
#7 0x4d1c06d in runOnModule
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1752:27
#8 0x4d1c06d in llvm::legacy::PassManagerImpl::run(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1865
#9 0xa48ca3 in compileModule(char**, llvm::LLVMContext&)
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:611:8
#10 0xa4270f in main
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:365:22
#11 0x7fec902572e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#12 0x971b69 in _start
(/b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc+0x971b69)
llvm-svn: 363105
cmtice
referenced
this pull request
May 3, 2023
https://llvm.org/docs/LangRef.html#llvm-powi-intrinsic The max length of the integer power of `llvm.powi` intrinsic is 32, and the value can be negative. If we use `int32_t` to store this value, `-Val` will underflow when it is `INT32_MIN` The issue was reported in D149033.
lanza
pushed a commit
to lanza/llvm-project
that referenced
this pull request
Feb 8, 2024
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.