[LLVMbugs] [Bug 18679] New: COFF line table debug info is wrong in the presence of __asm align 4
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Jan 30 15:09:53 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=18679
Bug ID: 18679
Summary: COFF line table debug info is wrong in the presence of
__asm align 4
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedbugs at nondot.org
Reporter: timurrrr at google.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
See test/DebugInfo/COFF/asm.ll:
; 1 void g(void);
; 2
; 3 void f(void) {
; 4 __asm align 4;
; 5 g();
; 6 }
Generates this code:
+0: calll _g
+5: ret
There's the following problem at debug info generation time.
The debug line table format is something like:
...
<number of lines>
...
<pc><line>
<pc><line>
...
<pc><line>
...
For each instruction on a new source code line, WinCodeViewLineTables generates
a new entry in the debug info.
The problem is that "__asm align 4" doesn't generate any code in the result
binary.
So for the above example the table looks like this:
...
3
...
+0x0 4
+0x0 5
+0x5 6
...
If a stack trace includes 'f' calling 'g', the symbolizer looks up '+0x0' in
the debug info line table and gets line 4 as the result. Thus, the line number
in the symbolized stack trace is wrong.
Is there a way to know whether a particular instruction generates any bytes?
It'd be very handy to just skip processing of such an __asm block while
generating the debug info.
--
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/20140130/935d2f7d/attachment.html>
More information about the llvm-bugs
mailing list