similar to: Increasing address pool reuse/reducing .o file size in DWARFv5

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

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

I think I get it now, thanks for explaining! >> On Jan 12, 2020, at 11:44 AM, David Blaikie via llvm-dev <llvm-dev at lists.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

On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > From: David Blaikie <dblaikie at gmail.com> > >> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto: > paul.robinson at sony.com> wrote: > >> There are many bits of DWARF-5 that haven’t been implemented. > > > > Got a short list, by chance? > > I

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5

Hi Victor, The work Wolfgang is doing should get us to the "minimum syntactically correct DWARF v5" stage, which we really wanted to have for LLVM 7.0. That is, once we have .debug_rnglists and .debug_loclists done, you can ask for DWARF 5 and get something that conforms to the spec. However, it won't conform if you ask for type units (I'm working on that) or split DWARF. If

Hello Wolfgang and team, I see that you are working on support of .debug_rnglists, I am interested in the feature too, could you please point me out what else left to be done so that I could help you? -- Best Regards, Victor Leschuk | Software Engineer | Access Softek

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

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

On Sat, May 30, 2020 at 8:50 PM Fangrui Song <maskray at google.com> wrote: > > On 2020-05-29, David Blaikie wrote: > >On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: > >> > On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> > >> > wrote: > >> > > > On 2020-05-28, David

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features but

On Thu, Jun 4, 2020 at 8:27 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Wednesday, June 3, 2020 5:31 PM > > To: Robinson, Paul <paul.robinson at sony.com> > > Cc: jh7370.2008 at my.bristol.ac.uk; llvm-dev at lists.llvm.org > >

On Sun, May 31, 2020 at 9:57 AM Fangrui Song <maskray at google.com> wrote: > > > On 2020-05-30, David Blaikie wrote: > >On Sat, May 30, 2020 at 8:50 PM Fangrui Song <maskray at google.com> wrote: > >> > >> On 2020-05-29, David Blaikie wrote: > >> >On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.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

Hi all, I've put this 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

On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Welcome Sourabh, > > > > There are many bits of DWARF-5 that haven’t been implemented. > Got a short list, by chance? > I know there is currently no big push within Sony to “fill in the > corners” for v5, as we have been more focused on quality of debug info for > optimized

Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const

"On Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul

Hello Everyone, I need to have your thoughts on this. Consider the following test case -- ------------------------------------------- 1 int main(int Argc, char **Argv) { 2 int Local = 6; 3 printf("%d\n",Local); 4 5 { 6 printf("%d\n",Local); 7 int Local = 7; 8 printf("%d\n",Local); 9 }