[llvm-bugs] [Bug 26191] New: Info from .cfi directives should by default go into .debug_frame, not .eh_frame section

[via llvm-bugs]

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

            Bug ID: 26191
           Summary: Info from .cfi directives should by default go into
                    .debug_frame, not .eh_frame section
           Product: tools
           Version: trunk
          Hardware: Macintosh
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-as
          Assignee: unassignedbugs at nondot.org
          Reporter: bart.jacobs at cs.kuleuven.be
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

It seems that the LLVM assembler currently, at least on OS X, always emits the
call frame information/stack unwinding information specified by the .cfi_xxx
directives into the .eh_frame section instead of the .debug_frame section.

I would argue that this is unsafe behavior. The user may only have the
debugging scenario in mind, not the run-time stack unwinding scenario. By
emitting the unwinding info into .eh_frame, the assembler causes the platform's
unwinder to walk the program's stack at run time (if the program calls into
Cocoa or some other Objective-C library, for example), possibly causing the
program to crash if the unwind info specified in the .cfi directives is
incorrect. (This has been causing my application to crash; see
http://caml.inria.fr/mantis/view.php?id=7118 .) The user may not be aware of
this source of instability, and may therefore be less careful about getting the
.cfi directives right.

As a general principle, I would propose that participating in the run-time
stack unwinding story should be an opt-in, not a default, due to the stability
risks involved.

-- 
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/20160118/3d7c75c9/attachment-0001.html>