search

mchalupa / dg

[LLVM Static Slicer] Various program analyses, construction of dependence graphs and program slicing of LLVM bitcode.
MIT License
474 stars 131 forks source link

Question about Multilingual Support #458

Open Y-LONG28 opened 1 month ago

Y-LONG28 commented 1 month ago

Hello,

I would like to inquire about the current support for other languages in dg. I am trying to convert Rust code to .bc using rustc and then perform program slicing with dg, but I am encountering issues with the slicing criteria. Below is a simple Rust program I am using:

fn main()
{   
    let a = 1; 
    let b = a + 1;
    let c = val();
    assert!(a==1);
    assert!(b==2,"Value of b should be 2");

}

fn val() ->i32{
    return 42;
}

Compilation command: rustc --emit=llvm-bc -C debuginfo=2 main.rs

Command to invoke dg: ./llvm-slicer -c __assert_fail /home/firepunch/slice-ex/main.bc

I have tried various slicing criteria such as -c val, -c 3:a, -c __assert_fail, and -c ret, but all return similar error messages:

I would like to know if the issue lies with my slicing criteria, differences between rustc and clang, or something else? Thank you!

Y-LONG28 commented 1 month ago

I have simplified my Rust code as follows:

fn main()
{   
    let a = 1; 
}

Compilation command: rustc --emit=llvm-bc -g test.rs

Slicing command: ./llvm-slicer -c 3:a -dump-dg /home/firepunch/slice-ex/test.bc >test.dot

The error message is as follows:

SC: Matched '3#a' to: 
    store i32 1, i32* %a.dbg.spill, align 4, !dbg !38
 ... and  1 more
[llvm-slicer] cutoff 2 diverging blocks and 21 completely removed
 #0 0x00007a94eee3fd01 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-14/lib/libLLVM-14.so.1+0xe3fd01)
 #1 0x00007a94eee3da0c llvm::sys::RunSignalHandlers() (/usr/lib/llvm-14/lib/libLLVM-14.so.1+0xe3da0c)
 #2 0x00007a94eee40236 (/usr/lib/llvm-14/lib/libLLVM-14.so.1+0xe40236)
 #3 0x00007a94ed842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x00007a94f4a4a4c2 llvm::Value::getValueID() const /usr/include/llvm-14/llvm/IR/Value.h:533:12
 #5 0x00007a94f4a4a4c2 llvm::Instruction::getOpcode() const /usr/include/llvm-14/llvm/IR/Instruction.h:158:49
 #6 0x00007a94f4a4a4c2 dg::pta::LLVMPointerGraphBuilder::isRelevantInstruction(llvm::Instruction const&) /home/firepunch/dg/lib/llvm/PointerAnalysis/PointerGraph.cpp:428:27
 #7 0x00007a94f4a51a74 dg::pta::LLVMPointerGraphBuilder::buildPointerGraphBlock(llvm::BasicBlock const&, dg::pta::PointerSubgraph*) /home/firepunch/dg/lib/llvm/PointerAnalysis/Block.cpp:36:9
 #8 0x00007a94f4a4b675 __gnu_cxx::__normal_iterator<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq* const*, std::vector<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*, std::allocator<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*> > >::__normal_iterator(dg::pta::LLVMPointerGraphBuilder::PSNodesSeq* const* const&) /usr/include/c++/11/bits/stl_iterator.h:1028:9
 #9 0x00007a94f4a4b675 std::vector<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*, std::allocator<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*> >::end() const /usr/include/c++/11/bits/stl_vector.h:839:16
#10 0x00007a94f4a4b675 std::vector<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*, std::allocator<dg::pta::LLVMPointerGraphBuilder::PSNodesSeq*> >::empty() const /usr/include/c++/11/bits/stl_vector.h:1008:30
#11 0x00007a94f4a4b675 dg::pta::LLVMPointerGraphBuilder::PSNodesBlock::empty() const /home/firepunch/dg/include/dg/llvm/PointerAnalysis/PointerGraph.h:98:49
#12 0x00007a94f4a4b675 dg::pta::LLVMPointerGraphBuilder::buildFunction(llvm::Function const&) /home/firepunch/dg/lib/llvm/PointerAnalysis/PointerGraph.cpp:587:22
#13 0x00007a94f4a4c28a dg::pta::LLVMPointerGraphBuilder::buildLLVMPointerGraph() /home/firepunch/dg/lib/llvm/PointerAnalysis/PointerGraph.cpp:648:24
#14 0x00006300849126c2 dg::DGLLVMPointerAnalysis::buildSubgraph() /home/firepunch/dg/include/dg/llvm/PointerAnalysis/PointerAnalysis.h:288:12
#15 0x00006300849126c2 dg::DGLLVMPointerAnalysis::initialize() /home/firepunch/dg/include/dg/llvm/PointerAnalysis/PointerAnalysis.h:310:22
#16 0x0000630084914518 std::__uniq_ptr_impl<dg::pta::PointerAnalysis, std::default_delete<dg::pta::PointerAnalysis> >::_M_ptr() const /usr/include/c++/11/bits/unique_ptr.h:173:58
#17 0x0000630084914518 std::unique_ptr<dg::pta::PointerAnalysis, std::default_delete<dg::pta::PointerAnalysis> >::get() const /usr/include/c++/11/bits/unique_ptr.h:422:27
#18 0x0000630084914518 std::unique_ptr<dg::pta::PointerAnalysis, std::default_delete<dg::pta::PointerAnalysis> >::operator->() const /usr/include/c++/11/bits/unique_ptr.h:416:12
#19 0x0000630084914518 dg::DGLLVMPointerAnalysis::run() /home/firepunch/dg/include/dg/llvm/PointerAnalysis/PointerAnalysis.h:332:24
#20 0x0000630084914518 dg::llvmdg::LLVMDependenceGraphBuilder::_runPointerAnalysis() /home/firepunch/dg/include/dg/llvm/LLVMDependenceGraphBuilder.h:80:18
#21 0x0000630084914518 dg::llvmdg::LLVMDependenceGraphBuilder::constructCFGOnly() /home/firepunch/dg/include/dg/llvm/LLVMDependenceGraphBuilder.h:202:28
#22 0x0000630084914518 Slicer::buildDG(bool) /home/firepunch/dg/tools/include/dg/tools/llvm-slicer.h:83:24
#23 0x000063008490af9b main /home/firepunch/dg/tools/llvm-slicer.cpp:223:5
#24 0x00007a94ed829d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#25 0x00007a94ed829e40 call_init ./csu/../csu/libc-start.c:128:20
#26 0x00007a94ed829e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#27 0x000063008490b655 _start (/home/firepunch/dg/build/tools/llvm-slicer+0xf655)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Segmentation fault (core dumped)
mchalupa commented 1 month ago

Hi,

I would like to know if the issue lies with my slicing criteria, differences between rustc and clang, or something else? Thank you!

I think the issue is in the difference between LLVM generated by rustc and clang. Although DG was not written with a specific compiler in mind, it was tested basically only on LLVM generated from C code with clang (C because DG does not support C++ exceptions). It seems that rust generates the debugging information somehow differently than clang. The crash from the other report could be that DG does not check for the nullptr (or this check is an assertion and your build is release) for some value that is alway present in the Clang-generated code, but not in rustc-generated code.