search for: kudrin

...bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have to have two versions of GC: one with parsing eh_frames and another without parsing. There can be input object files where .eh_frame is not split. -Evgeny From: Igor Kudrin <ikudrin at accesssoftek.com> Date: Friday, 10 November 2017 at 12:23 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: nd <nd at arm.com>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Making .eh_frame more linker...

...n one place or two? What do you mean “one place or two”? If .eh_frame_hdr is not created a linker does not need to parse .eh_frame sections. It simply merges them into one section. The format of .eh_frame allows to do this without parsing .eh_frame sections. Thanks, Evgeny Astigeevich From: Igor Kudrin <ikudrin.dev at gmail.com> Date: Thursday, 9 November 2017 at 11:29 To: Rui Ueyama <ruiu at google.com>, Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, nd <nd at arm.com> Subject: Re: [llvm-de...

...ubsan/logs/stdio I tried to reproduce the issue locally, but didn't succeed. Anyway, I've reapplied my patch (r266620) using the old format for .covmapping, and buildbots are happy now. Could you take a look on that? Do you have any idea what might cause the problem? Best regards, Igor Kudrin

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 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow m...

...may not be worth it after measuring > the speed difference. The idea is to do nothing if the size of each output debug section is less than 4GiB. Thus, a noticeable linking speed degradation will exist only for projects which would most probably just fail to link otherwise. Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.

....debug_str 53685f .debug_ranges 00c300 As you can see, ".debug_str" is visibly bigger than ".debug_info". Of course, CLANG does not suffer from DWARF32 limits. This is just a relatively large project, which anyone can easily check by themselves. -- Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.​

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

...oesn't provide this information, then it's a current behavior which also adheres to DWARF spec that says if DWARF32 and DWARF64 the onus is on 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...

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 -> SHT_DWARF64 or SHT_GNU_DWARF64 >>> >>> In LL...

...ronment, and lots of other circumstances. I've checked some fresh built samples and always see that the section is usually close in size to ".debug_info" and sometimes even bigger. So, this section must be ordered similarly as all other debugging info sections. -- Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.

...ed to existing standards. The committee may also have some thoughts on how tools are expected to work with DWARF64 and DWARF32 mixtures. > > James > > On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> 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 -> SHT_DWARF64 or SHT_GNU_DWARF...

This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a...

Hi, We would like to see that change, too, especially for lld/ELF. Chris, do you have a patch or just looking for help? Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> Sent: Friday, February 23, 2018 6:37 AM To: Chris Jackson Cc: llvm-dev Subject: Re: [llvm-dev] RFC: L...

...ich can be retroactively applied to existing standards. The committee may also have some thoughts on how tools are expected to work with DWARF64 and DWARF32 mixtures. James On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> 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 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > &...

...c.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] Support DWARF64, debug_info "sorting" On Thu, 12 Nov 2020 at 02:10, Fangrui Song <maskray at google.com<mailto:maskray at google.com>> wrote: On...

...ttee may also have some thoughts on how tools are expected to work > with DWARF64 and DWARF32 mixtures. > > > > James > > > > On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> 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...

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

...orted to the start? I guess so. On Tue, Nov 10, 2020 at 9:30 PM Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Wed, Nov 11, 2020 at 12:19 AM Alexander Yermolovich via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a...

...n type is **not decided yet** on > LLVM/GNU binutils sides. Our discussions on llvm-dev/binutils will > benefit from agreement/disagreement from generic-abi. Thank you for conducting all these discussions. I hope we will finally find a way to bring the feature alive. -- Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.

On Wed, Nov 11, 2020 at 12:19 AM Alexander Yermolovich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This year Igor Kudrin put in a lot of work in enabling DWARF64 support in > LLVM. At Facebook we are looking into it as one of the options for handling > debug information over 4gigs in production environment. One concern is that > due to mix of third party libraries and llvm compiled code the final > librar...