http://llvm.org/bugs/show_bug.cgi?id=16045
Bug ID: 16045
Summary: clang for iOS output very partial __debug_frame
section
Product: new-bugs
Version: unspecified
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: qsr at chromium.org
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
With the following clang version:
% clang -v
clang version 3.3 (trunk 179138)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
Given the following file:
---------------------------------------
void foo() {
}
int main() {
foo();
}
---------------------------------------
I compile it for iOS:
% clang -target arm-apple-darwin7 -g -c /tmp/main.c -o /tmp/main.o
Then looking at the __debug_frame section:
% otool -s __DWARF __debug_frame /tmp/main.o
/tmp/main.o:
Contents of (__DWARF,__debug_frame) section
0000025c 0000000c ffffffff 7c010001 0000000e
0000026c 0000000c 00000000 00000000 00000004
0000027c 0000000c 00000000 00000004 00000018
The section is useless to walk the stack.
Debugger can use the fp to do it, so they don't seem to even care about the
debug_frame section, but is it an expected behavior, or should the
__debug_frame contains the information on how to unwind the stack and retrieve
the register values?
--
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/20130517/dc4b87df/attachment.html>