similar to: CodeView and "line 0" ?

I mean, we just skip over instructions without a DebugLoc: void CodeViewDebug::beginInstruction(const MachineInstr *MI) { DebugHandlerBase::beginInstruction(MI); // Ignore DBG_VALUE locations and function prologue. if (!Asm || !CurFn || MI->isDebugValue() || MI->getFlag(MachineInstr::FrameSetup)) return; DebugLoc DL = MI->getDebugLoc(); if (DL == PrevInstLoc || !DL)

No, Object is supposed to be an abstraction over real object files and LLVM bitcode object files. Maybe we can break the CodeView -> Object dependency. On Thu, Mar 29, 2018 at 4:23 PM Zachary Turner <zturner at google.com> wrote: > It seems a little strange conceptually that object depends on > BitcodeReader. Is it possible to break that dependency? > On Thu, Mar 29, 2018 at

On Mon, Mar 26, 2018 at 4:52 PM David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: > >> On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I'm looking at fixing some layering violations in LLVM & came across a >>> few in the

It seems a little strange conceptually that object depends on BitcodeReader. Is it possible to break that dependency? On Thu, Mar 29, 2018 at 4:11 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Mar 26, 2018 at 4:52 PM David Blaikie <dblaikie at gmail.com> wrote: > >> On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: >>

On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a few > in the CodeView handling, specifically: > > lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers > I guess MC could be made dependent on DebugInfoCodeView? But probably > these things should be

On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: > On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > >> I'm looking at fixing some layering violations in LLVM & came across a >> few in the CodeView handling, specifically: >> >> lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers

I'm looking at fixing some layering violations in LLVM & came across a few in the CodeView handling, specifically: lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers I guess MC could be made dependent on DebugInfoCodeView? But probably these things should be sunk into BinaryFormat as is the case for DWARF features used by MC? include/llvm/Object/COFF.h includes

Yes, some of the headers and stuff that are just raw structure definitions and enums could probably be sunk into BinaryFormat.. How'd you find this? Curious why it hasn't been breaking in modules builds for a long time. On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a

Intuitively I'd think MC and DebugInfo should be independent. MC is a producer, DebugInfo is a consumer. What's common is the definition of the structures they operate on, which doesn't properly belong to either one. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Wednesday, March 21, 2018 11:52 AM To: Zachary Turner

DebugInfoCodeView is nto strictly a consumer, it is also a producer. On Wed, Mar 21, 2018 at 1:29 PM <paul.robinson at sony.com> wrote: > Intuitively I'd think MC and DebugInfo should be independent. MC is a > producer, DebugInfo is a consumer. What's common is the definition of the > structures they operate on, which doesn't properly belong to either one. > >

On Thu, Oct 29, 2015 at 12:42 PM, Daniel Dilts via cfe-dev < cfe-dev at lists.llvm.org> wrote: > 2. Will LLD and LLDB be updated as necessary to support CodeView? > Rui is is looking at making LLD link codeview from object files into PDBs. Zachary Turner intends to add PDB reading support to LLDB. We already have a PDB implementation of DIContext in lib/DebugInfo that uses PDBs. The

Someone internally's been dabbling with turning on some of Google's build system's stricter header checking modes - and they caught these (you can check the internal code review 184305506 for the original where I'm pulling things out from). & yeah, fair question about the modules builds - I don't fully understand what they catch and don't catch. I suspect it's a

Hi, Is there any way to debug the codeview output of llvm from within Visual Studio? I want to use the codeview line info debug output of clang/llvm. I tried with the x86_64-pc-windows-msvc and i686-pc-windows-msvc triples and linking it into an existing project with VC++ from within the IDE and outside with link /debug. Neither option lets me debug with Visual Studio as debugger host.

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 baseline .obj? Or would the test convert back from the .obj to some kind of text as

Hello, LLVM currently supports emission of CodeView's line table subsection. However, we'd like to increase the fidelity of this debug info with column information. I was wondering if anybody had any pointers as to how CodeView represents such information. Thanks! -- David Majnemer -------------- next part -------------- An HTML attachment was scrubbed... URL:

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

RFC: CodeView debug info emission in Clang/LLVM Overview On Windows, the de facto debug information format is CodeView, most commonly encountered in the form of a .pdb file. This is the format emitted by the Visual C++, C#, and VB.NET compilers, consumed by the Visual Studio debugger and the Windows debugger (WinDbg), and exposed for read-only access via the DIA SDK. The CodeView format has never

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

On Thu, Oct 29, 2015 at 2:08 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Oct 29, 2015, at 10:11 AM, Dave Bartolomeo via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Proposed Design > > How Debug Info is Generated > > The CodeView type records for a compilation unit will be generated by > the front-end

I also think that we should keep one representation of debug info in the LLVM IR. There would be a need to extend some of the debug info entries to support CodeView, but I think that most of the information generated today by Clang for Dwarf can be used for generating CodeView. I can think about two missing extensions that are needed to CodeView: 1. In Frontend: File Checksum, it is