search for: llvmcodeview

The LLVMCodeView library is definitely independent of the rest of the design questions. As far as testing goes, what would be the conventional LLVM way of testing a library for file format manipulation? A test tool that converts some simple text form into a .obj containing CodeView sections, and comparing with a b...

...ng emitted; for example, would having two dbg.declare intrinsics for a single local variable confuse existing consumers of LLVM IR? I'm hoping someone more familiar with the existing debug info architecture can provide some guidance here if there's a better way of doing this. New Library - LLVMCodeView The design introduces a new library in LLVM, "LLVMCodeView". This library will contain the code to read and write the CodeView debug info format. The library depends only on the LLVMSupport library, enabling non-LLVM clients to use the library without depending on large portions of LLVM....

...where he has trouble expressing CV information entirely in the backend. Regardless of what everyone ends up deciding on with regards to the front-end / back-discussion, I want to suggest separating the work into separate pieces that can go in independently of each other. For example, the proposed LLVMCodeView library, which simply reads and writes raw CV records, seems to be orthogonal to this discussion and could be submitted independently. On Sat, Oct 31, 2015 at 12:04 PM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The details of the mangling would be ABI dependent no...

...where he has trouble expressing CV information entirely in the backend. Regardless of what everyone ends up deciding on with regards to the front-end / back-discussion, I want to suggest separating the work into separate pieces that can go in independently of each other. For example, the proposed LLVMCodeView library, which simply reads and writes raw CV records, seems to be orthogonal to this discussion and could be submitted independently. I haven't looked at the patch in general, but that sounds quite plausible - unit tests or what-have-you that demonstrate the expected behavior regardless of we...

Brief answer, but can go into detail later: If this is the right idea, lets do it for dwarf too & generalize the support to work for both. It's certainly something we've considered, to save all the complexity of representing essentially static data in an intermediate form. That said, given some of the stuff we have for lto, for example (deallocating/merging types etc) I'm not