search for: high_pc

...tart_address:end_address. While resolving relocations, it would replace > such a range with 1:1. > However, It would not work if address ranges were specified as > start_address:length since the length is not relocated. > This case could be additionally fixed by fast scan debug_info for High_PC > defined as length and changing it to 1. Something which you suggested here: > http://lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html. > Hmm, I don't /think/ I intended to suggest anything that would have to parse all the debug_info, even if just to fixup high_pc. I meant that...

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 data addre...

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't supposed to contain relocations). In

> 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

...ally can't go into the DWO. >> > > DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as > they did exist (in a non-standard form) they have always supported > FORM_addr_index to reference addresses in .debug_addr in the main .o. > > But the low_pc/high_pc/ranges attributes would appear in the .dwo, using a > FORM_addr_index/FORM_addrx - so if you want to collect the address range of > a CU you might need to load the .dwo to do so. That's the crux of what I > was getting at: To get the address range a CU covers, you may need to read >...

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

...m-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 can avoi...

So there have been several recent discussions about the issues around DWARF-agnostic linking and gc-sections, linkonce function definitions being dropped, etc - and just how much DWARF-awareness would be suitable in a linker to help with this situation. I'd like to discuss a narrower instance of this issue: Zero length gc'd/deduplicated functions. LLVM seems to at least produce zero

...ms 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 think they w...

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

...; >> > > > > DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as > > they did exist (in a non-standard form) they have always supported > > FORM_addr_index to reference addresses in .debug_addr in the main .o. > > > > But the low_pc/high_pc/ranges attributes would appear in the .dwo, using > a > > FORM_addr_index/FORM_addrx - so if you want to collect the address range > of > > a CU you might need to load the .dwo to do so. That's the crux of what I > > was getting at: To get the address range a CU covers,...

...tps://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 declaration duri...

...he pool of addresses down to, ideally, one address per section/indivisible chunk of machine code (per subsection in MachO, for instance) (whereas currently there are many addresses per section) > >> How do you figure the offset out? > > Label difference - same as is done for DW_AT_high_pc today in DWARFv4 and DWARFv5 in LLVM. high_pc currently uses the low_pc addresse to be relative to, in this proposed situation, we'd use a symbol that's in the first bit of debug info in the section (or subsection in MachO). So the low_pc of the subprogram/function, for instance, or if ther...

Hi Oliver, There would be no problem if both the Map and the Vector indeed contained (Key,Value) pairs. To save space, Map entries do not contain Value but instead an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the

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

...range specified as start_address:end_address. While resolving relocations, it would replace such a range with 1:1. However, It would not work if address ranges were specified as start_address:length since the length is not relocated. This case could be additionally fixed by fast scan debug_info for High_PC defined as length and changing it to 1. Something which you suggested here: http://lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html<https://urldefense.com/v3/__http:/lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB...

...backend 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 think they would be huge, an...

..._address. While resolving >> relocations, it would replace such a range with 1:1. >> However, It would not work if address ranges were specified as >> start_address:length since the length is not relocated. This case could be >> additionally fixed by fast scan debug_info for High_PC defined as length >> and changing it to 1. Something which you suggested here: >> http://lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html >> <https://urldefense.com/v3/__http:/lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocD...

...ations, it would replace such a range with 1:1. > > >> However, It would not work if address ranges were specified as > > >> start_address:length since the length is not relocated. This case could > > be > > >> additionally fixed by fast scan debug_info for High_PC defined as > > length > > >> and changing it to 1. Something which you suggested here: > > >> https://urldefense.com/v3/__http://lists.llvm.org/pipermail/llvm- > > dev/2020-May/141599.html__;!!JmoZiZGBv3RvKRSx!sRjL4Vdx9oC8TPFhKZ- > > QbL7LtpIL-1Zdb4OydT2xVh...

...t; > > > >> However, It would not work if address ranges were specified as > > > > >> start_address:length since the length is not relocated. This case > > could > > > > be > > > > >> additionally fixed by fast scan debug_info for High_PC defined as > > > > length > > > > >> and changing it to 1. Something which you suggested here: > > > > >> https://urldefense.com/v3/__http://lists.llvm.org/pipermail/llvm- > > > > dev/2020-May/141599.html__;!!JmoZiZGBv3RvKRSx!sRjL4Vdx9oC8T...