similar to: CodeView layering

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

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, 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

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 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

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

Looks like maybe the CodeView -> Object dependency is out of date/old/not needed any more anyway... (don't see any Object headers included from the CodeView headers or implementation, etc). Will see if going that way internally is viable & loop back if it stumbles across something. On Thu, Mar 29, 2018 at 5:27 PM Reid Kleckner <rnk at google.com> wrote: > No, Object is

I've been playing with Fred Riss's "line 0" patch for DWARF (https://reviews.llvm.org/D16569) but in adapting it for current trunk, I find the DwarfDebug stuff has been refactored to allow either DWARF or CodeView. That's all good, but the question is whether the "line 0" patch should be DWARF-specific or common. The DWARF spec explicitly states that code not

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)

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

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:

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.

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 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

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

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 Mon, 15 Sep 2014 19:33:42 +0200, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Basically, see my patches to LLVM from early 2014 -- they include tests, > a DI generator and a DI dumper. I'd be happy to review your patches too! Thanks. Looks like it's likely that it's one of the 0xF1 sections, the first one always has the object file name and what seems