[llvm-bugs] [Bug 44074] New: Add option for the behavior of __register_frame/__deregister_frame in ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Nov 20 04:07:26 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=44074

            Bug ID: 44074
           Summary: Add option for the behavior of
                    __register_frame/__deregister_frame in
                    ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp
           Product: libraries
           Version: 9.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: MCJIT
          Assignee: unassignedbugs at nondot.org
          Reporter: albert.jin at gmail.com
                CC: 1101.debian at gmail.com, llvm-bugs at lists.llvm.org

I use the full set of libraries from LLVM working under Linux with no
dependency of gcc. While making use of LLVM MCJIT, I observed that there would
be an error message from `LLVMRunFunction`,

  libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE

By searching LLVM source code, I got two facts as follows.

- This message is produced by function `__unw_add_dynamic_fde()` in
`libunwind/src/libunwind.cpp`.
- In `llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp`, it is
assumed that the behavior of `__register_frame`/`__deregister_frame` from
libunwind depends on OS. It is checked by `#ifdef __APPLE__`.

libunwind, however, is actually a runtime shared library chosen at compile
time. For example, it can be specified to use libgcc or libunwind according to
the build option `CLANG_DEFAULT_UNWINDLIB`. It's true that the native libunwind
on macOS is from LLVM, and on Linux it is from gcc. But this does not prevent
programs for macOS from using the set of runtime libraries from gcc, and vice
versa.

I have made a fix by adding a new cmake option
`EXECUTION_ENGINE_USE_LLVM_UNWINDER`. My suggested patch is as attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191120/2c83412e/attachment.html>


More information about the llvm-bugs mailing list