search for: codeviewdebug

...81.) > I think if you remove locations from ConstantSDNodes, you might want to add a late pass that propagates source locations backwards onto location-less instructions. This would also avoid some special cases when a basic block starts with an instruction that lacks location information. See CodeViewDebug::beginInstruction and DwarfDebug::beginInstruction for what we do today. Interesting, I hadn't considered doing this. What happens in the special case where a block starts with a location-less instruction? Ah, I see that CodeViewDebug::beginInstruction does a forward scan to find the first in...

...> > I think if you remove locations from ConstantSDNodes, you might want to add a late pass that propagates source locations backwards onto location-less instructions. This would also avoid some special cases when a basic block starts with an instruction that lacks location information. See CodeViewDebug::beginInstruction and DwarfDebug::beginInstruction for what we do today. > > Interesting, I hadn't considered doing this. > > What happens in the special case where a block starts with a location-less instruction? Ah, I see that CodeViewDebug::beginInstruction does a forward sca...

Some time ago I saw a report of strange single-stepping behavior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if

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

...ode and find that the “-use-unknown-locations” option and its related logic is only supported for Dwarf debug info as below. These codes are missing in the Codeview side. It looks the “-use-unknown-locations” option logic is not complex, could we port the code logic into llvm\lib\CodeGen\AsmPrinter\CodeViewDebug.cpp as well? I’ve submitted a BZ for this requirment: https://bugs.llvm.org/show_bug.cgi?id=44522 llvm-project\llvm\lib\CodeGen\AsmPrinter\DwarfDebug.cpp : static cl::opt<DefaultOnOff> UnknownLocations( "use-unknown-locations", cl::Hidden, cl::desc("Make an absence of...

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

...ode and find that the “-use-unknown-locations” option and its related logic is only supported for Dwarf debug info as below. These codes are missing in the Codeview side. It looks the “-use-unknown-locations” option logic is not complex, could we port the code logic into llvm\lib\CodeGen\AsmPrinter\CodeViewDebug.cpp as well? I’ve submitted a BZ for this requirment: https://bugs.llvm.org/show_bug.cgi?id=44522 llvm-project\llvm\lib\CodeGen\AsmPrinter\DwarfDebug.cpp : static cl::opt<DefaultOnOff> UnknownLocations( "use-unknown-locations", cl::Hidden, cl::desc("Make an absence of...

...ng this proposal. 2. I understand that CodeView will need some extra extensions to current dwarf debug info, like ‘this’ adjustment. However, it is doable to introduce a CodeView wrapper data structures that can be created from current dwarf debug info IR. And this can be done in CodeGen (e.g. CodeViewDebug.cpp) while emitting the code/debug info. Again, I understand that your proposal is trying to improve a lot of things Yes, and to give some different perspective: some of these "things" are a lot higher priority than CodeView (for other people/use cases of course), because DebugInfo cost...

On Thu, 9 Jan 2020, David Blaikie via llvm-dev wrote: > +rnk who works on COFF debugging things. > >  My understanding is that this has nothing to do with the linker - but is a > function of LLVM optimizations creating line zero debug locations. I believe > rnk & folks have disabled line zero emission for CodeView debug info in some > manner - perhaps that needs a flag? or

Sounds good to me. You can also see llvm.codeview.annotation which does a similar thing, but it is modeled as having internal, invisible side effects. These should stay separate, but it may provide a guide for implementation. On Tue, Mar 27, 2018 at 7:41 PM Hsiangkai Wang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello all, > > I would like to enhance LLVM debug info

...l. > 2. I understand that CodeView will need some extra extensions to current dwarf debug info, like ‘this’ adjustment. > However, it is doable to introduce a CodeView wrapper data structures that can be created from current dwarf debug info IR. > And this can be done in CodeGen (e.g. CodeViewDebug.cpp) while emitting the code/debug info. > > Again, I understand that your proposal is trying to improve a lot of things Yes, and to give some different perspective: some of these "things" are a lot higher priority than CodeView (for other people/use cases of course), because Deb...

...derstand that CodeView will need some extra extensions to > current dwarf debug info, like ‘this’ adjustment. > > However, it is doable to introduce a CodeView wrapper data structures that > can be created from current dwarf debug info IR. > > And this can be done in CodeGen (e.g. CodeViewDebug.cpp) while emitting > the code/debug info. > > > > Again, I understand that your proposal is trying to improve a lot of things > > > > Yes, and to give some different perspective: some of these "things" are a > lot higher priority than CodeView (for other peo...

>> On Jun 21, 2018, at 18:38, Chris Lattner <clattner at nondot.org> wrote: >> >> >> >> On Jun 21, 2018, at 9:52 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I've been curious for a while whether SmallVectors have the right speed/memory tradeoff. It would be straightforward to shave off a couple of

Ok I understand more what you meant. In fact I don’t care about the pdb size, at least as a first step, so it won’t be a problem for me to have duplicated symbols. Concerning TypeIndices my plan if possible is not to generate a pdb for my jit and merge it, but instead directly extract debug info from a DwarfContext just after llvm::object::ObjectFile is emitted by the JIT engine and complete the

...17 janv. 2019 à 20:01, Zachary Turner <zturner at google.com> a écrit : > Well, is it possible to just hook up the CodeView debug info generator to > MCJIT? If you're not jitting, and you just compile something, we translate > all of the LLVM metadata into CodeView in the file CodeViewDebug.cpp. > Then, the object file just already has CodeView in it. If it's not hard to > do, this would probably be a better solution, because you don't have to > worry about *how* to translate DWARF into CodeView, which is not always > trivial. > > If you can configure this i...

...;>>>>>>>>>>>> generator to MCJIT? If you're not jitting, and you just compile something, >>>>>>>>>>>>> we translate all of the LLVM metadata into CodeView in the file >>>>>>>>>>>>> CodeViewDebug.cpp. Then, the object file just already has CodeView in it. >>>>>>>>>>>>> If it's not hard to do, this would probably be a better solution, because >>>>>>>>>>>>> you don't have to worry about *how* to translate D...

...;>>>>>>>> generator to MCJIT? If you're not jitting, and you just compile something, >>>>>>>>>>>>>>> we translate all of the LLVM metadata into CodeView in the file >>>>>>>>>>>>>>> CodeViewDebug.cpp. Then, the object file just already has CodeView in it. >>>>>>>>>>>>>>> If it's not hard to do, this would probably be a better solution, because >>>>>>>>>>>>>>> you don't have to worry about *how...

Hello all, I would like to enhance LLVM debug info that supports setting breakpoint on labels in function. Generally, if users use GDB as their debugger, they could set breakpoints on labels in function. Following is an example. // C program static int myfunction (int arg) { int i, j, r; j = 0; /* myfunction location */ r = arg; top: ++j; /* top location */ if (j == 10) goto

Hi All, This is something that's been talked about for some time and it's probably time to propose it. The "We" in this document is everyone on the cc line plus me. Please go ahead and take a look. Thanks! -eric Objective (and TL;DR) ================= Migrate debug type information generation from the backends to the front end. This will enable: 1. Separation of