similar to: [RFC] - Deduplication of debug information in linkers (LLD).

Hi all ! We have an issue with LLD, it is "relocation R_X86_64_32 out of range" (PR31109) which occurs during resolving relocations in debug sections. It looks happens because .debug_info section can be too large sometimes and 32x relocation is not enough to represent the value. One of possible solutions looks to be to deduplicate information to reduce .debug_info size. The rest of

At least one proprietary linker put a lot of effort into deduplicating and rewriting debug information. This took up the majority of the link time despite serious engineering time on performance optimisation. For example, some sections were written from scratch by the linker because that proved faster than parsing the input. Teaching LLD to dedup DWARF should be expected to dramatically slow it

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only

Debuginfo and linker folks, we (AccessSoftek) would like to suggest a proposal for removing obsolete debug info. If you find it useful we will be happy to work on improving it. Thank you for any opinions and suggestions. Alexey.     Currently when the linker does garbage collection a lot of abandoned debug info is left behind (see Appendix A for documentation). Besides inflated debug info size,

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on

19.09.2019 4:24, David Blaikie пишет: > > > On Wed, Sep 18, 2019 at 7:25 AM Alexey Lapshin <a.v.lapshin at mail.ru > <mailto:a.v.lapshin at mail.ru>> wrote: > > >> > Generally speaking, dsymutil does a very similar thing. It parses > DWARF DIEs, analyzes relocations, scans through references and > throws out unused DIEs. But it`s current

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the

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

As has been mentioned elsewhere, Sony generally fixes up references from debug info to stripped functions (of any length) using -1, because that's a less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base address for shared libraries, I'd think using it has the potential to mislead various consumers.) For .debug_ranges we use -2, because both a 0/0 pair and a -1/-1 pair

On Thu, May 28, 2020 at 6:03 AM Alexey Lapshin <alapshin at accesssoftek.com> wrote: > Hi David, > > > >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

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 -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >>

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

On Fri, Nov 13, 2020 at 11:29 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:24 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: >

24.09.2019 8:26, Rui Ueyama пишет: > Hi Alexey, > > Thank you for sharing this proposal. Reducing the size of debug info > is generally a good thing, and I believe you'd see more debug info > size reduction in Rust programs than in C++ programs, because I heard > that the Rust compiler driver passes a lot of object files to the > linker, expecting that the linker would

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: > > --------------------- > > Option b) I am going to expand David's description with more details, > correct me if I am wrong. > > I'll let David continue this part of the thread with you. > > >

On 04/26/2013 19:50, Jiong Wang wrote: > > > why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, > I think generation of R_X86_64_32 is reasonable. > > you can check http://dwarfstd.org/doc/DWARF4.pdf. Because R_X86_64_32 elements are 4-byte addresses and can't be relocated for the 64-bit address space over 32-bit limit. Dwarf2 actually allows for

On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: Fangrui Song <maskray at google.com> > > Sent: Friday, May 29, 2020 1:07 AM > > To: David Blaikie <dblaikie at gmail.com> > > Cc: Robinson, Paul <paul.robinson at sony.com>; Alexey Lapshin > >

On Tue, Sep 24, 2019 at 11:22 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alexay, > > Thank you for the detailed explanation. The other question I have is, as > discussed above, about dsymutil. You said that dsymutil is not usable at > link-time. What does that mean? If we only have to emit an output file in > the usual way and then automatically