Mctoll crashes when running raising ARM binary

[testhound]

Running mctoll on this program:

long g1;

attribute((noinline)) int func(int a, char b, short c, long d, long e, int f, int g) {
int temp = (a + f) * (int) c - (int) e;
int temp2 = temp + (int) (b * b);
int tf = (d + g) * 3 + temp + temp2;

return b + tf + temp2;
}

int a1, f1;
long e1;
char b1;
short c1;
long d1;

int main(int argc, char **argv) {
return (int) func (a1, b1, c1, d1, e1, f1, g1);
}

Compiled with arm-linux-gnueabi-gcc version 7.5 (-Os) gives this crash and backtrace:

llvm-mctoll: /home/collison/Raiser/llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:138: llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::reference llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::operator*() const [with OptionsT = llvm::ilist_detail::node_options<llvm::MachineBasicBlock, true, false, void>; bool IsReverse = true; bool IsConst = false; llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::reference = llvm::MachineBasicBlock&]: Assertion `!NodePtr->isKnownSentinel()' failed.
#0 0x0000563df73c5955 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/collison/Raiser/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:0
#1 0x0000563df73c59e8 PrintStackTraceSignalHandler(void*) /home/collison/Raiser/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:0
#2 0x0000563df73c3779 llvm::sys::RunSignalHandlers() /home/collison/Raiser/llvm-project/llvm/lib/Support/Signals.cpp:68:0
#3 0x0000563df73c52d2 SignalHandler(int) /home/collison/Raiser/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:0
#4 0x00007f4a3b385890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#5 0x00007f4a3a681e97 gsignal /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x00007f4a3a683801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
#7 0x00007f4a3a67339a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
#8 0x00007f4a3a673412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
#9 0x0000563df60fec2d llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::MachineBasicBlock, true, false, void>, true, false>::operator*() const /home/collison/Raiser/llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:139:0
#10 0x0000563df60fdd81 llvm::simple_ilistllvm::MachineBasicBlock::back() /home/collison/Raiser/llvm-project/llvm/include/llvm/ADT/simple_ilist.h:140:0
#11 0x0000563df60fd19a llvm::MachineFunction::back() /home/collison/Raiser/llvm-project/llvm/include/llvm/CodeGen/MachineFunction.h:726:0
#12 0x0000563df60fabdb MCInstRaiser::buildCFG(llvm::MachineFunction&, llvm::MCInstrAnalysis const*, llvm::MCInstrInfo const*) /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/MCInstRaiser.cpp:118:0
#13 0x0000563df60f62c5 ModuleRaiser::runMachineFunctionPasses() /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/MachineFunctionRaiser.cpp:109:0
#14 0x0000563df60657ad DisassembleObject(llvm::object::ObjectFile const*, bool) /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/llvm-mctoll.cpp:1443:0
#15 0x0000563df60675b4 DumpObject(llvm::object::ObjectFile*, llvm::object::Archive const*) /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/llvm-mctoll.cpp:1734:0
#16 0x0000563df6067bdf DumpInput(llvm::StringRef) /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/llvm-mctoll.cpp:1794:0
#17 0x0000563df607a214 void (std::for_each<__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > >, void ()(llvm::StringRef)>(__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > >, __gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > >, void ()(llvm::StringRef)))(llvm::StringRef) /usr/include/c++/7/bits/stl_algo.h:3883:0
#18 0x0000563df6067fb3 main /home/collison/Raiser/llvm-project/llvm/tools/llvm-mctoll/llvm-mctoll.cpp:1843:0
#19 0x00007f4a3a664b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
#20 0x0000563df605faea _start (../../../../../build/bin/llvm-mctoll+0x30daea)

NOTE: X86 compiles but raises the binary incorrectly due too the number of arguments. It appears the X86 does not handle more than four parameters.

[bharadwajy]

Thanks for the report.

At present, llvm-mctoll recognizes function arguments passed in GPRs (i.e., RDI, RSI, RDX, RCX, R8, R9 - as specified by AMD64 ABI). So, support to identify arguments of functions with 6 or less args is implemented.

Support to identify functions whose args are passed on stack (i.e., > 6 args) or via XMM registers needs to be implemented.

While it is on the list of features to be added, any help is highly appreciated.

[testhound]

Hi Bharadwaj, I discovered the limitations of the X86 implementation. The reported I submitted was for the Arm port, which does not seem to have the limitation of the x86 port. Regards, Michael Collison

…

On Apr 12, 2020, at 6:35 PM, S. Bharadwaj Yadavalli ***@***.***> wrote:  Thanks for the report. At present, llvm-mctoll recognizes function arguments passed in GPRs (i.e., RDI, RSI, RDX, RCX, R8, R9 - as specified by AMD64 ABI). So, support to identify arguments of functions with 6 or less args is implemented. Support to identify functions whose args are passed on stack or via XMM registers needs to be implemented. While it is on the list of features to be added, any help is highly appreciated. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bharadwajy]

Thanks for the clarification, Michael.

While I did note that the crash was reported for ARM binary, I was merely clarifying that the tool is expected to raise x86-64 binaries comprising of functions with 6 or less register arguments (not 4). That's all :-) As you noted in the initial report, this is most likely the reason for incorrect result from raising an x86 binary comprising of functions with more than 6 arguments.

Implementation of ARM raiser can also use some help and attention to ensure that it can handle all the test cases x86-64 raiser currently can.

[testhound]

I will be working on a RISC-V port so I will be unable to improve X86 or ARM support unless the issues are generic. This is the main reason I filed this report, the backtrace seems to indicate a problem in MCInstRaiser::buildCFG; are you aware of any issues in the area?

[bharadwajy]

I am not aware of any issues in CFG construction. It is relatively simple and relies on MCInst info .

Any generic improvements while you work on a RISC-V port are gratefully appreciated.

[leibo-hust]

Hi, Do u have any ideas of the Issue #68 , it's really very important to me, I don't know where is the problem. Thanks a lot!

[bharadwajy]

Hi, Do u have any ideas of the Issue #68 , it's really very important to me, I don't know where is the problem. Thanks a lot!

It is not clear to me which aspect of #68 you are having trouble with. Please refer to the comments of that issue.

Please add any additional questions or comments to the relevant issue to minimize mis-communication.

Thanks!