search for: debug_loc

...tr:$MI0, instr:$MI1), (match (G_ZEXT $t0, $S):$MI0, (G_TRUNC $D, $t0):$MI1), (isScalarType type:$D), (isLargerType type:$D, type:$S)), (apply (G_ZEXT $D, $S, (debug_locations $MI0, $MI1)))>; def : GICombineRule<(defs reg:$D, reg:$S, instr:$MI0, instr:$MI1, instr:$MI2, instr:$MI3, debug_expr:$DNewExpr), (match (G_ZEXT $t0, $S):$MI0, (G_TRUNC $D, $t0):$MI1, (DBG_VALUE $t0...

...email in a different thread, although it is quite similar to some of the threads on tombstoning etc, with similar underlying structural issues. Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections properly, I ran into an object in the game code I was using as my input where a v4 .debug_loc section had a location description that looked something like this: .quad foo .quad foo ... # location description where foo was a section symbol, i.e. the start and end address were the same. Consequently, there would be two relocations with 0 addend patching the start and end offset. When I was...

...>> (apply (G_ZEXT $D, $S))>; >> def : GICombineRule<(defs reg:$D, reg:$S, instr:$MI0, instr:$MI1), >> (match (G_ZEXT $t0, $S):$MI0, >> (G_TRUNC $D, $t0):$MI1), >> (isScalarType type:$D), >> (isLargerType type:$D, type:$S)), >> (apply (G_ZEXT $D, $S, (debug_locations $MI0, $MI1)))>; >> def : GICombineRule<(defs reg:$D, reg:$S, instr:$MI0, instr:$MI1, instr:$MI2, instr:$MI3, debug_expr:$DNewExpr), >> (match (G_ZEXT $t0, $S):$MI0, >> (G_TRUNC $D, $t0):$MI1, >>...

...he small set of machines I'm familiar > >> > with.) > >> > > Certainly the toolchain community would benefit from making it be the > >> > > same everywhere. > >> > > > >> > > Personally I'd vote for -1, and make pre-v5 .debug_loc/.debug_ranges > >> > > sections be an extra-special case using -2. We can (I hope) standardize > >> > > on -1 for v6 onward, and document -1/-2 on the DWARF wiki as recommended > >> > > practice for prior versions. > >> > > >> >...

...gt; > > and wrapping was undefined on the small set of machines I'm familiar > > with.) > > > Certainly the toolchain community would benefit from making it be the > > > same everywhere. > > > > > > Personally I'd vote for -1, and make pre-v5 .debug_loc/.debug_ranges > > > sections be an extra-special case using -2. We can (I hope) standardize > > > on -1 for v6 onward, and document -1/-2 on the DWARF wiki as recommended > > > practice for prior versions. > > > > That'd make linking difficult - the unix...

...; >> >> > with.) > >> >> > > Certainly the toolchain community would benefit from making it be the > >> >> > > same everywhere. > >> >> > > > >> >> > > Personally I'd vote for -1, and make pre-v5 .debug_loc/.debug_ranges > >> >> > > sections be an extra-special case using -2. We can (I hope) standardize > >> >> > > on -1 for v6 onward, and document -1/-2 on the DWARF wiki as recommended > >> >> > > practice for prior versions. > >&g...

...to the point whether they wrap. They've been unsigned > and wrapping was undefined on the small set of machines I'm familiar with.) > Certainly the toolchain community would benefit from making it be the > same everywhere. > > Personally I'd vote for -1, and make pre-v5 .debug_loc/.debug_ranges > sections be an extra-special case using -2. We can (I hope) standardize > on -1 for v6 onward, and document -1/-2 on the DWARF wiki as recommended > practice for prior versions. That'd make linking difficult - the unix linkers at least, currently don't have to ide...

...premature debug_range termination with zero-length functions (Clang >> > produces these with __builtin_unreachable or non-void return >> >type functions >> > without a return statement) >> > >> >New behavior: >> > >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier >> > there) >> > - -1 elsewhere >> > - linker flag to customize to other values if desired >> > >> >Known issues: >> > >> > - lldb's line table parsing can't handle -1 well at all (e...

...And the 'bfd' semantics may get stale if GNU ld updates its behaviors. We can also take it from another perspective, do the opt-in options look intimidating just because they are too long? -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' We can support signed integers: -z 'dead-reloc-in-nonalloc=.debug_ranges=-2' -z 'dead-reloc-in-nonalloc=.debug_loc=-2' -z 'dead-reloc-in-nonalloc=.debug_*=-1' Three options seem too lo...

...DwarfDebug class doesn't emit the line number table as a series of bytes: // If the target is using .loc/.file, the assembler will be emitting the // .debug_line table automatically. if (MAI->hasDotLocAndDotFile()) return; Previously .loc directives are printed by selecting ISD::DEBUG_LOC nodes to pseudo instructions which print as the directive. For example: def DWARF_LOC : Pseudo<(outs), (ins i32imm:$line, i32imm:$col, i32imm:$file), ".loc $file, $line, $col", [(dwarf_loc (i32 imm:$line), (i32 imm:$col), (i32 imm:$file))]>; ISD::DEBUG_LOC...

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jul 27, 2020 at 9:11 AM Robinson, Paul <paul.robinson at sony.com> wrote: >> >> > I still...

...> We can also take it from another perspective, do the opt-in options look > > >> intimidating just because they are too long? > > >> > > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' > > >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' > > >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' > > >> > > >> We can support signed integers: > > >> > > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=-2' > > >> -z 'dead...

...ld updates its behaviors. >> >> We can also take it from another perspective, do the opt-in options look >> intimidating just because they are too long? >> >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' >> >> We can support signed integers: >> >> -z 'dead-reloc-in-nonalloc=.debug_ranges=-2' >> -z 'dead-reloc-in-nonalloc=.debug_loc=-2' >> -z 'dead-...

...Wed, Aug 5, 2020 at 12:13 PM Hans Wennborg <hans at chromium.org> wrote: > My apologies, I didn't realize D84825 now restores the original > behavior. The review thread is a bit hard to follow :-) > > From the change description it still sounds like .debug_ranges & > .debug_loc tombstones are changing to -2 though? Or is that what we > had before? > > To be clear, I'm not familiar with the technical details here, I'm > just keen that we end up in a known-good state. > > Also the patch is marked "release/11.x only". Normally we land chan...

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

...romium.org> wrote: > >> > >> My apologies, I didn't realize D84825 now restores the original > >> behavior. The review thread is a bit hard to follow :-) > >> > >> From the change description it still sounds like .debug_ranges & > >> .debug_loc tombstones are changing to -2 though? Or is that what we > >> had before? > > https://reviews.llvm.org/D84825 restored the behavior. I mean, with > respect, I do not know why it was marked as "request for changes". > Otherwise, it would have been resolved a week ago....

...ltin_unreachable or non-void return >> >> >> >type functions >> >> >> > without a return statement) >> >> >> > >> >> >> >New behavior: >> >> >> > >> >> >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier >> >> >> > there) >> >> >> > - -1 elsewhere >> >> >> > - linker flag to customize to other values if desired >> >> >> > >> >> >> >Known issues: >...

...ch >> more interesting case. In that situation, -1 (or -2) seems like a much >> wiser choice of blessed-as-not-real address, versus 0x0 or 0x1. >> >> >> >> Stripping non-zero-length functions does mean you have to care about more >> sections. For example .debug_locs would want to be fixed up the same way >> as .debug_ranges, not because a debugger would care but so that dumpers >> would not run into the 0/0 brick wall. >> > >Yep - in theory a consumer could actually use a loclist across multiple >sections (if a global variable got h...

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b). On Fri, Jul 24, 2020 at 9:33 AM Hans Wennborg <hans at chromium.org> wrote: > On Fri, Jul 24, 2020 a...

...Clang >> >> > produces these with __builtin_unreachable or non-void return >> >> >type functions >> >> > without a return statement) >> >> > >> >> >New behavior: >> >> > >> >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier >> >> > there) >> >> > - -1 elsewhere >> >> > - linker flag to customize to other values if desired >> >> > >> >> >Known issues: >> >> > >> >> > - l...