[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