similar to: CodeView layering

Displaying 20 results from an estimated 2000 matches similar to: "CodeView layering"

2018 Mar 21
2
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
2018 Mar 21
0
CodeView layering
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
2018 Mar 21
0
CodeView layering
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
2018 Mar 21
1
CodeView layering
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. > >
2018 Mar 26
2
CodeView layering
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
2018 Mar 29
2
CodeView layering
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: >>
2018 Mar 22
0
CodeView layering
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
2018 Mar 29
0
CodeView layering
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
2018 Mar 30
0
CodeView layering
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
2018 Apr 01
0
CodeView layering
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
2016 Aug 17
2
CodeView and "line 0" ?
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
2016 Aug 17
2
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)
2015 Nov 03
3
[cfe-dev] RFC: CodeView debug info emission in Clang/LLVM
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
2015 Jul 07
2
[LLVMdev] Column information for the CodeView debug info format
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:
2014 Sep 15
2
[LLVMdev] codeview debug info in Visual Studio
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.
2015 Oct 30
3
RFC: CodeView debug info emission in Clang/LLVM
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
2016 Mar 03
5
[cfe-dev] RFC: CodeView debug info emission in Clang/LLVM
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
2015 Nov 04
2
[cfe-dev] RFC: CodeView debug info emission in Clang/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
2015 Oct 31
3
[cfe-dev] RFC: CodeView debug info emission in Clang/LLVM
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
2014 Sep 15
2
[LLVMdev] codeview debug info in Visual Studio
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