search for: ayermolo

...e to give it a shot at implementing and collecting some performance numbers. 🙂 Alex ________________________________ From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Thursday, November 12, 2020 2:20 AM To: Fangrui Song <maskray at google.com> Cc: Alexander Yermolovich <ayermolo at fb.com>; Robinson, Paul <paul.robinson at sony.com>; David Blaikie <dblaikie at gmail.com>; Eric Christopher <echristo at gmail.com>; Igor Kudrin <ikudrin at accesssoftek.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [LLD]...

On Thu, Nov 12, 2020 at 4:43 PM Alexander Yermolovich <ayermolo at fb.com> wrote: > > Looks like there is an agreement that this path, modifying lld to order sections using relocations, should be explored. > If Igor doesn't object, since he was primary one driving DWARF64 so far, I would like to give it a shot at implementing and collecting some...

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Tuesday, November 17, 2020 1:51 AM > To: Alexander Yermolovich <ayermolo at fb.com> > Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher > <echristo at gmail.com&g...

On 19.11.2020 03:21, Cary Coutant wrote: >>> If the .debug_str section *by itself* exceeds 4GB, then yes any string >>> with a 32-bit reference to it must be in the first 4GB. Strings that >>> have only 64-bit references to them can be sorted to the end of the >>> section, if necessary. I wouldn't think anyone guarantees or cares >>> about the

...user. Alex ________________________________ From: Fāng-ruì Sòng <maskray at google.com> Sent: Tuesday, November 17, 2020 4:49 PM To: Igor Kudrin <ikudrin at accesssoftek.com> Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; Alexander Yermolovich <ayermolo at fb.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Robinson, Paul <paul.robinson at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher <echristo at gmail.com> Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sor...

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 2020-11-17, Igor Kudrin wrote: > >On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 ->

...rdering within the output .debug_str section. Thank You Alex ________________________________ From: Fāng-ruì Sòng <maskray at google.com> Sent: Friday, November 13, 2020 12:42 PM To: David Blaikie <dblaikie at gmail.com> Cc: Wenlei He <wenlei at fb.com>; Alexander Yermolovich <ayermolo at fb.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Robinson, Paul <paul.robinson at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher <echristo at gmail.com>; Igor Kudrin <ikudrin at accesssoftek.com> Subject: Re: [llvm...

...skray at google.com> Sent: Wednesday, November 11, 2020 2:59 PM To: Robinson, Paul <paul.robinson at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk> Cc: David Blaikie <dblaikie at gmail.com>; Eric Christopher <echristo at gmail.com>; Alexander Yermolovich <ayermolo at fb.com>; Igor Kudrin <ikudrin at accesssoftek.com>; 'llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting" (Adding back Cc: which got dropped) > (Igor - I don't know what happened, bu...

On 2020-11-12, Alexander Yermolovich wrote: >Thanks for feedback. > >I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. > >"Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects

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: >

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer