"Exception terminator 'invoke' is not supported yet"

[aytey]

I am using rellic at commit: 86280f6

The system I'm running this on is:

uname -a
Linux ubnt2204 5.15.0-101-generic #111-Ubuntu SMP Tue Mar 5 20:16:58 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

Here's my example:

target triple = "x86_64-unknown-linux-gnu"

define i32 @example() personality ptr null {
start:
  %_0 = invoke i32 null()
          to label %bb1 unwind label %cleanup

cleanup:                                          ; preds = %start
  %0 = landingpad { ptr, i32 }
          cleanup
  ret i32 0

bb1:                                              ; preds = %start
  ret i32 0
}

Which I assemble and try to decompile as follows:

${HOME}/lifting-bits-downloads/vcpkg_ubuntu-22.04_llvm-16_amd64/installed/x64-linux-rel/bin/llvm-as input.ll -o input.bc

${HOME}/rellic/rellic-build/install/usr/local/bin/rellic-decomp --input input.bc --output output.c

Note: I'm using the llvm-as that gets pulled down by vcpkg when building rellic from source (so hopefully everything is compatible).

When I run this, I get the following error:

F20240328 15:54:29.826215 2473702 Decomp.cpp:130] /home/avj/rellic/lib/AST/GenerateAST.cpp:260 Exception terminator 'invoke' is not supported yet
*** Check failure stack trace: ***
    @     0x55811609ba56  google::LogMessage::SendToLog()
    @     0x558116097fb4  google::LogMessage::Flush()
    @     0x55811609c1ef  google::LogMessageFatal::~LogMessageFatal()
    @     0x558115ab70ad  main
    @     0x7f8052b47d90  (unknown)
    @     0x7f8052b47e40  __libc_start_main
    @     0x558115ab6315  _start
    @              (nil)  (unknown)
Aborted (core dumped)

Here is how the backtrace to /home/avj/rellic/lib/AST/GenerateAST.cpp:260 looks in gdb:

#0  rellic::GenerateAST::GetOrCreateEdgeCond (this=0x55555d00b838, from=0x55555cffdc90, to=0x55555cffdfa0) at /home/avj/rellic/lib/AST/GenerateAST.cpp:260
#1  0x000055555622a8b4 in rellic::GenerateAST::CreateReachingCond (this=0x55555d00b838, block=0x55555cffdfa0) at /home/avj/rellic/lib/AST/GenerateAST.cpp:290
#2  0x000055555622d219 in rellic::GenerateAST::run (this=0x55555d00b838, func=..., FAM=...) at /home/avj/rellic/lib/AST/GenerateAST.cpp:604
#3  0x000055555624f241 in llvm::detail::PassModel<llvm::Function, rellic::GenerateAST, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisMan
ager<llvm::Function>&) (this=0x55555d00b830, IR=..., AM=...)
    at /home/avj/lifting-bits-downloads/vcpkg_ubuntu-22.04_llvm-16_amd64/installed/x64-linux-rel/include/llvm/IR/PassManagerInternal.h:89
#4  0x00005555599d5d2c in llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) ()
#5  0x000055555622d9b5 in rellic::GenerateAST::run (module=..., dec_ctx=...) at /home/avj/rellic/lib/AST/GenerateAST.cpp:661
#6  0x0000555555fe5002 in rellic::Decompile (module=std::unique_ptr<llvm::Module> = {...}, options=...) at /home/avj/rellic/lib/Decompiler.cpp:97
#7  0x0000555555fb5f91 in main (argc=1, argv=0x7fffffffdff8) at /home/avj/rellic/tools/decomp/Decomp.cpp:125

[frabert]

I think I'll have to file this one under "won't fix" -- there is no clear way to express the kind of behavior LLVM expects with regards to exception handling in pure C.

[aytey]

Okay, would it be feasible to get rellic to simply ignore (maybe with a message?) a routine it cannot support, while still translating the routines it does?

Right now, if any routine uses invoke, then the whole file cannot be translated; having a “best attempt, sacrificing routines we don’t support” would be very handy.

Also, should the error message for this one be changed then? It isn’t really “yet” if it won’t ever be supported :)

[frabert]

Okay, would it be feasible to get rellic to simply ignore (maybe with a message?) a routine it cannot support, while still translating the routines it does?

Right now, if any routine uses invoke, then the whole file cannot be translated; having a “best attempt, sacrificing routines we don’t support” would be very handy.

I'd say it would be feasible but out of scope for Rellic. This would be akin to modifying the bitcode before going into Rellic itself, which is something downstream users should be able to do relatively easily: it's essentially an LLVM pass that goes through every function that contains invoke or landing pads and deletes its body/substitutes it with an unreachable instruction.

Also, should the error message for this one be changed then? It isn’t really “yet” if it won’t ever be supported :)

Heh that's a fair point. I guess it's not really "it won't ever be supported" as much as it is a "we don't know what this looks like yet".

Right now we don't really have an internal use for Rellic anymore so it's not receiving active updates, but if we did want to support exceptions we'd need to think about the fact that there's probably multiple ways to represent them in C (setjmp/longjmp, or maybe straight-up emitting C++) and the users will probably want to have a way to configure Rellic's behavior.

[aytey]

Thanks for the feedback, @frabert!

I'd say it would be feasible but out of scope for Rellic.

Okay, understood.

Heh that's a fair point. I guess it's not really "it won't ever be supported" as much as it is a "we don't know what this looks like yet".

Maybe it isn't "won't fix" but more "highly non-trivial and something we're nowhere near addressing" then? That can collide in practical terms with "won't fix", but does actually have a different meaning.

[frabert]

Sure, that wording may be too strong. The GitHub button says "Close as not planned" and I'd say that's the perfect description: we are not planning on implementing this feature in the foreseeable future :)