similar to: New llvm.commandline named metadata

> On Nov 13, 2018, at 1:07 PM, Reid Kleckner <rnk at google.com> wrote: > > Overall, I think we should do this. It's one of the most popular out of tree extensions that people make to LLVM and clang, and we want it for codeview anyway. Why isn't OPT_dwarf_debug_flags good enough for codeview? -- adrian > We currently don't emit a command line there. Other than

Hi all, In an effort to improve compatibility on the CodeView debug info side, we need to output a few new record types on the backend that don't seem to have the necessary info tracked by the debug info metadata. Specifically: 1) For each compile unit, we need to emit a record containing the output file name (e.g. foo.obj) 2) For each compile unit, we need to emit a record containing the

On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: > +pcc, who had some other ideas/patch out for improving memory usage of > debug info > +Reid, who's responsible for the windows/CodeView/PDB debug info which is > motivating some of the ideas about changes to type emission > > So I discussed this with Adrian and Mehdi at the social last

Hi All,   Can we extract name of variable name from "MDNode" ?   1. Neither temp_MDNode->getName() nor temp_MDNode->getValueName() give me "global_int" which is name of a variable.   2. I tried below ways as well. DIVariable DV(mdnode1); Value *v = mdnode1->getOperand(0);//gives add 0x69   3. I have written below code to reach till variable name.        LLVMIname is

+pcc, who had some other ideas/patch out for improving memory usage of debug info +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about changes to type emission So how does this relate, or not, to Peter's (pcc) work trying to reduce the DIE overhead during code gen? Are you folks chasing different memory bottlenecks? Are they both

> On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: >> +pcc, who had some other ideas/patch out for improving memory usage of debug info >> +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about

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

I have no objections to any of this FWIW :) -eric On Tue, Mar 29, 2016 at 6:46 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> +pcc, who had some other

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

I was just trying to build lldb-6.0 from source (and had previously successfully build llvm-6.0, clang-6.0, and lld-6.0 from source), but received a compile error while using both just cmake and cmake+ninja Does this look familiar to anyone? In file included from llvm/lldb-6.0.0.src/source/API/SystemInitializerFull.cpp:89: In file included from

I'm still trying to figure this out. On one of my machines it went away after a clean install even though my configuration is exactly the same. I'll let you know once I know more. On Wed, May 16, 2018 at 5:28 PM Davide Italiano <davide at freebsd.org> wrote: > + Jonas who hit the same bug recently. > > On Wed, May 16, 2018 at 8:01 AM, Eric Gorr via llvm-dev >

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

> On Mar 22, 2016, at 8:04 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +pcc, who had some other ideas/patch out for improving memory usage of debug info > +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about changes to type emission > > So how does this relate, or not, to Peter's (pcc) work trying to

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

Hi Mehdi, I understand the reasoning for supporting this proposal independently from CodeView support. However, I do not think that it is needed for supporting CodeView. When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal. Also, it is not that clear from the proposal what will be shared (generic)

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

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)

+ Jonas who hit the same bug recently. On Wed, May 16, 2018 at 8:01 AM, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I was just trying to build lldb-6.0 from source (and had previously > successfully build llvm-6.0, clang-6.0, and lld-6.0 from source), but > received a compile error while using both just cmake and cmake+ninja > > Does this look familiar to