search for: low_pc

...d standard v5 DW_TAG_call_site, call site parameters, addresses, etc. So picking up from some of the design discussion in https://reviews.llvm.org/D72489: Me (Blaikie): I'm not sure why AT_call_return_pc would be needed at a tail call site as the debugger must ignore it. As for emitting DW_AT_low_pc under gdb tuning, I think this might be an artifact from the original GNU implementation. Djordje: Yes, that is the GNU implementation's heritage (I cannot remember why GCC generated the low_pc info in the case of the tail calls), but GNU GDB needs the low_pc (as an address) in order to handl...

There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn'...

...s.llvm.org> wrote: >  > > >> On Fri, Jan 10, 2020 at 12:57 PM Vedant Kumar <vedant_kumar at apple.com> wrote: >> I don't totally follow the proposed encoding change & would appreciate a small example. >> >> Is the idea to replace e.g. an 'AT_low_pc (<direct address>) + relocation for <direct address>' with an 'AT_low_pc (<indirection into a pool of addresses> + offset)', > > With Split DWARF or with DWARFv5 in LLVM at the moment, all addresses are indirected already. So it's: > > Replace "A...

I don't totally follow the proposed encoding change & would appreciate a small example. Is the idea to replace e.g. an 'AT_low_pc (<direct address>) + relocation for <direct address>' with an 'AT_low_pc (<indirection into a pool of addresses> + offset)', s.t. the cost of a relocation for the address is paid down the more it's used? How do you figure the offset out? thanks, vedant > On Ja...

David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the >> skeleton CU rather than the DWO CU. So it's quite possible that to get the >> address ranges covered by the CU one would need to look in the DWO, I think? >> >> Is that not correct/have I misunderstood something there? >> >> The DWO isn'...

On some previous occasion that introduced additional indirection (don't remember the details) my debugger people groused about the additional performance cost of chasing down data in a different object-file section. So we (Sony) might be happier with low_pc as expressions, than with a ranges-always solution. But hard to say without data, and getting both modes in at least as a temporary thing sounds like a good plan. --paulr > -----Original Message----- > From: aprantl at apple.com <aprantl at apple.com> > Sent: Wednesday, January 8,...

...allowing "base_address" then offset_pairs (an improvement over similar functionality in DWARFv4 because the offset pairs can be uleb encoded - so they can be quite compact)) But one place that DWARFv5 misses to reduce relocations further is direct addresses from debug_info, such as DW_AT_low_pc. For a while I've wondered if we could use an extension form for addr+offset, and I prototyped this without an extension attribute, but instead using exprloc. This has slightly higher overhead to express the... expression. (it's 9 bytes in total, could be as few as 5 with a custom form) B...

On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > If you only want code addresses, why not use the CU's > low_pc/high_pc/ranges > - those are guaranteed to be only code addresses, I think? > In the common case, for most targets LLVM supports I think you're right, but for my case, regrettably, not. Because my target is a Harvard Architecture, any code address can have the same ordinal value as any da...

...pindola at gmail.com> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > > wrote: > > > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the > >> skeleton CU rather than the DWO CU. So it's quite possible that to get > the > >> address ranges covered by the CU one would need to look in the DWO, I > think? > >> > >> Is that not correct/have I misunderstood something there? >...

...2020 at 5:37 PM, David Blaikie wrote: > On Wed, Mar 11, 2020 at 8:09 AM Luke Drummond > <luke.drummond at codeplay.com> > wrote: > > > On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > > > If you only want code addresses, why not use the CU's > > > low_pc/high_pc/ranges > > > - those are guaranteed to be only code addresses, I think? > > > > > In the common case, for most targets LLVM supports I think you're right, > > but for my case, regrettably, not. Because my target is a Harvard > > Architecture, any code...

?Hi ! I have a question about code used for collecting ranges. I was trying to fix PR35199. Its issue that it calls unreachable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339):

...and llvm-dwarfdump will choke (hopefully cleanly, but still) on an object file that uses DWARF segment selectors. The point of .debug_aranges is to accelerate the search for the appropriate CU. Yes you can spend time trolling through .debug_info and .debug_abbrev, decoding the CU DIEs looking for low_pc/high_pc pairs (or perhaps pointers to .debug_ranges) and effectively rebuild a .debug_aranges section yourself, if the compiler/linker isn’t kind enough to pre-build the table for you. I don’t understand why .debug_aranges should be discouraged; I shouldn’t think they would be huge, and consumers...

...e relatively low code addresses can't just be resolved to "addend" because then [0, length) of the large function might overlap into that code address range") could be modified by a DWARF-aware linker to remove the unused chunks. The DWARF that describes a specific function using low_pc/high_pc - it may be split into a .dwo file and unreachable by the linker - so it /needs/ a magic value for the address referenced by the low_pc to indicate that it is invalid. Which all comes back to "we probably need to pick a value that's explicitly invalid" and -2 (max - 1) seems...

...l table to find all the functions in an > object or executable, and the instruction/address they start at. Or, if you > are using debug info for some reason, you could look in the debug_info > rather than the line table, and find the DW_TAG_subprogram for each > function and look at its low_pc. > > On Fri, Jun 1, 2018 at 3:36 AM Muhui Jiang via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi >> >> I am using LLVM Pass combined with dwarf debug information to get all the >> function's start address. My steps are below: >> >&gt...

...eferences. > I don't think it'd reduce debug_addr references - I'm setting it up to only use the base address of the function start and everything's offset pairs from there, so loclists shouldn't create any addr entries, only using existing ones needed for the function's low_pc/CU's ranges, etc. I don't know what our current variable location tracking would ever likely manage to preserve the location information enough for it to cover the whole scope (or at least not often) & then pick a default location as the most common used location across that scope. (I&...

...end seems to > have this problem with an ambiguous debug_aranges entries. > > >> The point of .debug_aranges is to accelerate the search for the >> appropriate CU. Yes you can spend time trolling through .debug_info and >> .debug_abbrev, decoding the CU DIEs looking for low_pc/high_pc pairs (or >> perhaps pointers to .debug_ranges) and effectively rebuild a .debug_aranges >> section yourself, if the compiler/linker isn’t kind enough to pre-build the >> table for you. I don’t understand why .debug_aranges should be >> discouraged; I shouldn’t thin...

Hi I am using LLVM Pass combined with dwarf debug information to get all the function's start address. My steps are below: First, I write the function pass to get the start line of each function, which is finished. Then, based on the start line of every single function, I try to query the specific line from the dwarf's line binary table, which is generated with llvm-dwarfdump

Hello I've been looking at a debuginfo issue on an out-of-tree target which uses DWARF aranges. The problem is that aranges are generated for both data and code objects, and the debugger gets confused when program addresses overlap data addresses. The target is a Harvard Architecture CPU, so the appearance of overlapping address ranges is not in itself a bug as they reside in different

> Subject: Re: [llvm-dev] Range lists, zero-length functions, linker gc > > On 2020-05-28, David Blaikie wrote: > >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> > >wrote: > > > >> As has been mentioned elsewhere, Sony generally fixes up references > from > >> debug info to stripped functions (of any length) using

...iew - https://reviews.llvm.org/D54747#1505462 . Currently, DWARFLinker/dsymutil has the same problem. It could be solved using the fact that DWARFLinker analyzes debuginfo. It could recognize debug info generated for the module and keep it(compile units containing debug info for modules do not have low_pc, high_pc). 6. -flto=thin That problem was described in this review https://reviews.llvm.org/D54747#1503720. It also exists in current DWARFLinker/dsymutil implementation. I think that problem should be discussed more: it could probably be fixed by avoiding generation of such incomplete declara...