search for: dw_op

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM would be relatively easy I think) would be a bit...

...On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Hey guys, >> >> Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) I think it always depends on what you are debugging. When I’m interested whether the encoding is correct, I think I’d prefer to have all these details in there, even if they are re...

...at 10:08 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >>> >>> Hey guys, >>> >>> Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) > > I think it always depends on what you are debugging. When I’m interested whether the encoding is correct, I think I’d prefer to have all these details in there, even if t...

...prantl at apple.com>> wrote: On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote: Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) I think it always depends on what you are debugging. When I’m interested whether the encoding is correct, I think I’d prefer to have all these details in there, even if they are re...

...at references the dummy argument, N. call void @llvm.dbg.declare(metadata i64* %N, metadata !113, metadata !DIExpression()) … !110 = !DIFortranArrayType(baseType: !7, elements: !111) !111 = !{ !112 } !112 = !DIFortranSubrange(lowerBound: 1, upperBound: !113, upperBoundExpression: !DIExpression(DW_OP_deref)*)* !113 = !DILocalVariable(scope: !2, name: “zb1”, file: !3, type: !4, flags: DIFlagArtificial) It turned out that gdb didn’t properly interpret location lists or variable references in the DW_AT_lower_bound and DW_AT_upper_bound attribute forms, so the compiler must generate either a co...

On Fri, Jan 10, 2020 at 7:02 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > Hi, > > On Wed, Jan 8, 2020 at 8:38 PM Adrian Prantl <aprantl at apple.com> wrote: > > As far as LLVM semantics are concerned, the implicit pointer doesn't > seem to be that much different from any other implicit values (such as > constants) to me. Why do you think that it

...ily should model in LLVM IR. > Oh, yeah, that's certainly my intent in making this suggestion, that these artificial variables would not be part of the LLVM IR and only generated in the backend (& perhaps not generated at all in some conditions if/where we decide to support an extension DW_OP that's more similar to what I'm suggesting to use at the IR level). Thanks for describing/clarifying that explicitly. > > >> I get the feeling that allowing more options here will come > >> out as more conditions / branching elsewhere, in a way we could try to > &g...

...ursday, November 14, 2019 5:32 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* Adrian Prantl <aprantl at apple.com>; AlokKumar.Sharma at amd.com; Jonas > Devlieghere <jdevlieghere at apple.com>; llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: DW_OP_implicit_pointer design/implementation in general > > > > > > > > On Thu, Nov 14, 2019 at 1:53 PM Robinson, Paul <paul.robinson at sony.com> > wrote: > > My reading of the DWARF issue is that it was fairly specifically designed > to handle the case of a fun...

...on that references the dummy argument, N. call void @llvm.dbg.declare(metadata i64* %N, metadata !113, metadata !DIExpression()) … !110 = !DIFortranArrayType(baseType: !7, elements: !111) !111 = !{ !112 } !112 = !DIFortranSubrange(lowerBound: 1, upperBound: !113, upperBoundExpression: !DIExpression(DW_OP_deref)) It would be better (and much more robust in presence of optimizations) if the DIExpression were part of a @llvm.dbg.declare / value intrinsic tying the DILocalVariable to an LLVM SSA value. !113 = !DILocalVariable(scope: !2, name: “zb1”, file: !3, type: !4, flags: DIFlagArtificial) It turn...

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more