<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 6:17 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In general I do think we're going to need to abstract it out as much<br>
as possible. I'm not sure what the previous patch looks like, but<br>
abstracting the interface out would be general goodness for this. We<br>
can talk about designs for that as we move on. As far as how to<br>
migrate the decision down we can have it both as an option to code gen<br>
maybe or, for now, make it dependent upon triple. The former is, I<br>
think, the best option there.<br>
<br>
I'm not sure if you're going to want to support both debug info at the<br>
same time, but it's a readonly format at debug emission so I don't see<br>
it as being a problem. -Zmlt makes sense as the clang-cl name, or just<br>
make it whatever the debug mode flag is for cl.exe - this is at least<br>
a start down that path.<br></blockquote><div><br></div><div>I'd just use /Z7, since that's the cl.exe flag for the compatible format. This will need a long-form clang -cc1 flag name, though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the best way for the tests will be to write a set of parsers,<br>
etc that can dump the info. I realize this is likely a very large<br>
undertaking as well, but it seems like the only way to ensure we're<br>
getting some decent testing out.<br>
<br>
Any other questions I missed?<br>
<br>
-eric<br>
<br>
<br>
On Mon, Nov 18, 2013 at 9:14 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>> wrote:<br>
> I wrote some more lit tests for my patch and realized I was generating<br>
> some redundant info. This is fixed now. Attached is a new version<br>
> of the prototype patch with some more tests.<br>
><br>
> 2013/11/15 Joćo Matos <<a href="mailto:ripzonetriton@gmail.com">ripzonetriton@gmail.com</a>>:<br>
<div class="im">>> Hi Timur,<br>
>><br>
>> There's also a pending patch adding CodeView support in Phab:<br>
>> <a href="http://llvm-reviews.chandlerc.com/D165" target="_blank">http://llvm-reviews.chandlerc.com/D165</a><br>
><br>
</div>> I haven't looked at your patch yet, but based on the very low phab<br>
> review number, I'm pretty sure there are good reasons this wasn't<br>
> committed.<br>
<div class="im">><br>
>> Does your patch provide just a subset of the CodeView debug info provided in<br>
>> the other patch?<br>
><br>
</div>> Yes. I prefer small incremental changes.<br>
> Also, the file:line debug info is much much more important for me atm<br>
> than the other types of debug info.<br>
<div class="im">><br>
>> Looking at the patch, I think the approach the other patch took of<br>
>> abstracting the emission of debug information is a bit cleaner and it will<br>
>> probably make life easier when adding more debug formats in the future.<br>
><br>
</div>> Why wasn't the "abstract the emission of DI" part of that patch<br>
> reviewed/committed separately?<br>
<div class="HOEnZb"><div class="h5">><br>
>> On Fri, Nov 15, 2013 at 4:39 PM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> 2013/11/14 Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>>:<br>
>>> > 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>
>>> I found the MCAsmStreamer being used by llc which gives a decent text<br>
>>> 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>
>>><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>
>>> Attached is an updated patch with a new test and a few minor things<br>
>>> 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>
>>><br>
>>> > Thanks!<br>
>>> > --<br>
>>> > Timur Iskhodzhanov,<br>
>>> > Google<br>
>>><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>
>><br>
>><br>
>><br>
>> --<br>
>> Joćo Matos<br>
<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>
</div></div></blockquote></div><br></div></div>