[LLVMbugs] [Bug 16249] LLVM generates broken debug info on Windows

[bugzilla-daemon at llvm.org]

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

Vadim <chega_ at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #10 from Vadim <chega_ at yahoo.com> ---
(In reply to comment #7)
> so did I. Vadim: did you try latest HEAD? (fix was in
> http://llvm.org/viewvc/llvm-project?rev=187656&view=rev)

I've just tried my repro scenario with clang+llvm built from yesterday's master
branches of the respective repos (I'm using git mirror repos), and
unfortunately debugging is still broken.  The initial symbol loading appears to
work, but stepping through code doesn't.  Here's gdb output:
---
...
Reading symbols from c:\test\repro.clang.exe...done.
(gdb) start
Temporary breakpoint 1 at 0x3d0 (2 locations)
Starting program: c:\test\repro.clang.exe
[New Thread 23844.0x4ad0]
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x3d0: Input/output error.
(gdb)
---

At a glance, the difference from gcc-generated assembly seems that clang now
uses .secrel32 relocs even for references to code segment (e.g. ".secrel32
Lfunc_begin0").  After I manually replaced those with .long's, I could step
through the resulting binary in gdb.

Perhaps some analysis of DIE form is required to make this stuff work?

Also, I am a bit uneasy about making relocation type decision in
AsmPrinter::EmitLabelPlusOffset.  It looks like a low-level routine that might
get used to emit other types of information besides 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/20130807/1ad30ff0/attachment.html>