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 your motivation is to help reduce the number of relocations needed, then working on the .debug_addr section is definitely the next step. This will reduce relocations in pretty much every other DWARF section. If you have other goals, let us know what they are. Thanks, --paulr> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via > llvm-dev > Sent: Thursday, July 12, 2018 1:08 PM > To: vleschuk at accesssoftek.com; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] debug_rnglists status > > Hi Victor! > > I am just about to commit https://reviews.llvm.org/D49214, the first > implementation of .debug_rnglists. As you can probably see from the review > it generates the v5 range list table with range list entries using > primarily the DW_RLE_start_length and DW_RLE_offset_pair entry kinds (and > DW_RLE_end_of_list and DW_RLE_base_address). So what is currently missing > is the following: > > - Support for split DWARF. I think this requires first support for > .debug_addr, because we need to generate at least DW_RLE_base_addressx > entries (or the CU needs to set its DW_AT_low_pc referencing the > .debug_addr section). If that's in place we can generate all the *x entry > kinds (DW_RLE_startx_endx etc.) > > - Generating the offset table and using DW_FORM_rnglistx with the > DW_AT_ranges attribute. This should cut down further on the relocations > the linker needs to perform. > > Also, I am currently working on a refactor of the .debug_rnglists dumper > (reader) part. The rationale is that the location list table in > .debug_loclists is identical in layout to the range list table, and so I > want to take advantage of that. > > Let me know if you have any more questions. > > Cheers, > Wolfgang > > > -----Original Message----- > > From: Victor Leschuk [mailto:vleschuk at accesssoftek.com] > > Sent: Thursday, July 12, 2018 2:24 AM > > To: Pieb, Wolfgang; LLVM Dev > > Cc: aprantl at apple.com; David Blaikie > > Subject: debug_rnglists status > > > > 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hello Paul, thanks a lot for the top. I will try to look into .debug_addr section and ask questions if any. On 07/12/2018 08:32 PM, paul.robinson at sony.com wrote:> 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 your motivation is to help reduce the number of relocations needed, > then working on the .debug_addr section is definitely the next step. > This will reduce relocations in pretty much every other DWARF section. > > If you have other goals, let us know what they are. > Thanks, > --paulr > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via >> llvm-dev >> Sent: Thursday, July 12, 2018 1:08 PM >> To: vleschuk at accesssoftek.com; llvm-dev at lists.llvm.org >> Subject: Re: [llvm-dev] debug_rnglists status >> >> Hi Victor! >> >> I am just about to commit https://reviews.llvm.org/D49214, the first >> implementation of .debug_rnglists. As you can probably see from the review >> it generates the v5 range list table with range list entries using >> primarily the DW_RLE_start_length and DW_RLE_offset_pair entry kinds (and >> DW_RLE_end_of_list and DW_RLE_base_address). So what is currently missing >> is the following: >> >> - Support for split DWARF. I think this requires first support for >> .debug_addr, because we need to generate at least DW_RLE_base_addressx >> entries (or the CU needs to set its DW_AT_low_pc referencing the >> .debug_addr section). If that's in place we can generate all the *x entry >> kinds (DW_RLE_startx_endx etc.) >> >> - Generating the offset table and using DW_FORM_rnglistx with the >> DW_AT_ranges attribute. This should cut down further on the relocations >> the linker needs to perform. >> >> Also, I am currently working on a refactor of the .debug_rnglists dumper >> (reader) part. The rationale is that the location list table in >> .debug_loclists is identical in layout to the range list table, and so I >> want to take advantage of that. >> >> Let me know if you have any more questions. >> >> Cheers, >> Wolfgang >> >>> -----Original Message----- >>> From: Victor Leschuk [mailto:vleschuk at accesssoftek.com] >>> Sent: Thursday, July 12, 2018 2:24 AM >>> To: Pieb, Wolfgang; LLVM Dev >>> Cc: aprantl at apple.com; David Blaikie >>> Subject: debug_rnglists status >>> >>> 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 >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Best Regards, Victor Leschuk | Software Engineer | Access Softek
Note that debug_addr support is already present for pre-DWARFv5 fission/split-dwarf support. I imagine the thing to do for DWARFv5 support is to generalize this for non-split-DWARF cases, etc. Happy to help, code review, etc. This stuff as I've dabbled a fair bit with the original split DWARF support over the years. (though echristo originally implemented most of it) On Fri, Jul 13, 2018 at 7:39 AM Victor Leschuk via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello Paul, > > thanks a lot for the top. I will try to look into .debug_addr section > and ask questions if any. > > > On 07/12/2018 08:32 PM, paul.robinson at sony.com wrote: > > 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 your motivation is to help reduce the number of relocations needed, > > then working on the .debug_addr section is definitely the next step. > > This will reduce relocations in pretty much every other DWARF section. > > > > If you have other goals, let us know what they are. > > Thanks, > > --paulr > > > > > >> -----Original Message----- > >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > via > >> llvm-dev > >> Sent: Thursday, July 12, 2018 1:08 PM > >> To: vleschuk at accesssoftek.com; llvm-dev at lists.llvm.org > >> Subject: Re: [llvm-dev] debug_rnglists status > >> > >> Hi Victor! > >> > >> I am just about to commit https://reviews.llvm.org/D49214, the first > >> implementation of .debug_rnglists. As you can probably see from the > review > >> it generates the v5 range list table with range list entries using > >> primarily the DW_RLE_start_length and DW_RLE_offset_pair entry kinds > (and > >> DW_RLE_end_of_list and DW_RLE_base_address). So what is currently > missing > >> is the following: > >> > >> - Support for split DWARF. I think this requires first support for > >> .debug_addr, because we need to generate at least DW_RLE_base_addressx > >> entries (or the CU needs to set its DW_AT_low_pc referencing the > >> .debug_addr section). If that's in place we can generate all the *x > entry > >> kinds (DW_RLE_startx_endx etc.) > >> > >> - Generating the offset table and using DW_FORM_rnglistx with the > >> DW_AT_ranges attribute. This should cut down further on the relocations > >> the linker needs to perform. > >> > >> Also, I am currently working on a refactor of the .debug_rnglists dumper > >> (reader) part. The rationale is that the location list table in > >> .debug_loclists is identical in layout to the range list table, and so I > >> want to take advantage of that. > >> > >> Let me know if you have any more questions. > >> > >> Cheers, > >> Wolfgang > >> > >>> -----Original Message----- > >>> From: Victor Leschuk [mailto:vleschuk at accesssoftek.com] > >>> Sent: Thursday, July 12, 2018 2:24 AM > >>> To: Pieb, Wolfgang; LLVM Dev > >>> Cc: aprantl at apple.com; David Blaikie > >>> Subject: debug_rnglists status > >>> > >>> 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 > >>> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > Best Regards, > > Victor Leschuk | Software Engineer | Access Softek > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180713/0160b2b6/attachment.html>