<div dir="ltr">Hi Timur,<div><br></div><div>There's also a pending patch adding CodeView support in Phab: <a href="http://llvm-reviews.chandlerc.com/D165">http://llvm-reviews.chandlerc.com/D165</a></div><div><br></div>
<div>Does your patch provide just a subset of the CodeView debug info provided in the other patch?</div><div><br></div><div>Looking at the patch, I think the approach the other patch took of abstracting the emission of debug information is a bit cleaner and it will probably make life easier when adding more debug formats in the future.</div>
<div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 4:39 PM, Timur Iskhodzhanov <span dir="ltr"><<a href="mailto:timurrrr@google.com" target="_blank">timurrrr@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/11/14 Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>>:<br>
<div><div class="h5">> Hi David, Eric, LLVM devs,<br>
><br>
> You've probably heard about AddressSanitizer (ASan) and other<br>
> sanitizers based on LLVM. One of the things that makes ASan<br>
> not as awesome on Windows as it is on Linux<br>
> is the symbolization of the stacks.<br>
><br>
> Currently, ASan runtime on Windows uses<br>
> CaptureStackBackTrace/SymFromAddr/SymGetLineFromAddr64<br>
> to unwind and symbolize stacks. This works like a charm<br>
> in-process for stack frames built with CL, but yields<br>
> "function+0x0ff537" for frames built with Clang.<br>
><br>
> I came up with a prototype which emits "old-style debug info" COFF<br>
> sections that are sufficient to get function name / filename /<br>
> linenumber information. That's pretty much everything that's required<br>
> for ASan to work beautifully in terms of the completeness of error<br>
> reports.<br>
><br>
> Attached is a prototype patch which I've tried on some simple tests,<br>
> including some more complex ones with weird #line constructions.<br>
> It also works just great on ASan/Win tests without any link/run-time<br>
> warnings (I had a bunch of those during development, so I can tell it<br>
> works rather than fails silently).<br>
><br>
> I didn't have time to work on threading the command-line flags into<br>
> the AsmPrinter yet, so currently it just replaces DWARF entirely.<br>
> Of course, this should be fixed before this lands into trunk.<br>
> Currently, one can try this patch by using "clang-cl -Xclang -g ...".<br>
> Eventually we should have some dedicated flag for clang-cl.<br>
><br>
> Can you please take a look at the patch and suggest a good path forward?<br>
><br>
> I'm very unfamiliar with LLVM CodeGen/MC, so I'm pretty sure I made a<br>
> few weird things in the code... I've also put a few TODOs with<br>
> questions and suggestions.<br>
><br>
> Some general questions:<br>
> 1) Threading flags from the driver down to CodeGen.<br>
> How do we do that? Should we support all 4 combinations<br>
> of no-info/DWARF/CVLT/both?<br>
> How about "-Zmlt" as the clang-cl flag name? ("minimal line tables")<br>
><br>
> 2) Am I right that DWARF is pretty much the only debug info format<br>
> supported by LLVM/AsmPrinter right now? Do we want to take<br>
> an effort to come up with a generic debuginfogenerator interface<br>
> to share between DwarfDebug and WinCodeViewLineTables?<br>
> Then AsmPrinter should just hold a SmallVector<DebugInfoEmitter*><br>
> rather than a pair of DD/DE pointers.<br>
><br>
> 3) How would you suggest to write WinCodeViewLineTables tests<br>
> given that dumpbin is not available everywhere except Windows?<br>
> // Yeah, I should have looked at the DwarfDebug LIT tests and<br>
> // written some; but the prototype development went faster<br>
> // than I expected...<br>
<br>
</div></div>I found the MCAsmStreamer being used by llc which gives a decent text format.<br>
I wrote a simple x86+x86_64 .ll test and FileCheck expectations for<br>
the llc asm output.<br>
Is this the right approach to write tests?<br>
If so, I'll convert my remaining C program test cases into such an<br>
.ll+llc tests.<br>
<div class="im"><br>
> Can you suggest ways to split this patch so it's easier<br>
> to review part-by-part before this hits trunk?<br>
<br>
</div>Attached is an updated patch with a new test and a few minor things improved.<br>
I also removed the "TODO: test on X64" as I did try it on x64 and no<br>
changes were required.<br>
<br>
Looking forward to your feedback!<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks!<br>
> --<br>
> Timur Iskhodzhanov,<br>
> Google<br>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Joćo Matos
</div>