[LLVMbugs] [Bug 18636] New: Add support for producing DWARF CFI unwind info for ARM

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Jan 27 13:49:32 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18636

            Bug ID: 18636
           Summary: Add support for producing DWARF CFI unwind info for
                    ARM
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: llc
          Assignee: mseaborn at chromium.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

llc currently supports producing ARM EABI/EHABI unwind info for ARM (when
passed the option "-arm-enable-ehabi"), but not DWARF CFI unwind info.  I'd
like to add support for the latter.

My main motivation is that PNaCl currently uses DWARF CFI when targeting ARM so
that it can use the same DWARF unwinding code on all targets (without having to
build an EABI-based unwinder specially for ARM).  I'd like to be able to
upstream PNaCl's DWARF+ARM changes.

I think DWARF CFI support will be useful more generally, though.  Other reasons
for adding it include:

 1) For parity with GCC, which emits DWARF CFI directives when given "-g".
 2) For use by GDB.  I think GDB can read ARM prologs, but this typically isn't
guaranteed to work for complex prologs.
 3) DWARF CFI can specify the frame state at every instruction, so can work for
backtracing after an asynchronous interruption, whereas I think EABI unwind
info is only accurate at call sites.
 4) As debugging info, DWARF CFI info can be stripped, but I'm not sure if EABI
unwind info can.
 5) Producing DWARF CFI is useful for tools like Breakpad.  There has been some
work on getting Breakpad to read EABI unwind info, but it's not committed:
https://code.google.com/p/google-breakpad/issues/detail?id=503

-- 
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/20140127/203310fa/attachment.html>


More information about the llvm-bugs mailing list