similar to: Possible UB in reading coverage mapping with compressed function names

> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way, > does it make sense to make this change to simplify only a small part of a linker? For huge C++ projects this could improve link time if GC is a 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:

Hi Igor, > It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right? Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to. > So, is there any difference whether it knows that in one place

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 mixed SHT_PROGBITS and SHT_DWARF64. If > > all

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

Thanks Alexander for bringing this up! > The major drawback in sorting, is the need to parse DWARF, even a little bit > of it (only the first 4 bytes of a section to tell which version it is - first 12 if you > want to be able to jump over contributions and check /all/ contributions > coming from a given input object file (it might contain a combination of > DWARFv4 and DWARFv5)

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

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 performance numbers. 🙂 Alex ________________________________ From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent:

Hi Scott, It's possible they've missed it, so I've explicitly CC'ed a number of the usual DWARF suspects, at least some of whom are on the standards committee. I don't have anything specific to add myself. James On Mon, 27 Apr 2020 at 15:25, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I don't know what an acceptable ping rate on an RFC is, but I also

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

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

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections,

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

On Fri, Oct 9, 2015 at 3:58 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Oct 7, 2015 at 11:12 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> There is no further response to this, so I will assume general >> direction of solution-3 is acceptable ;) > No response does not mean "LGTM". > What I meant is that

There is no further response to this, so I will assume general direction of solution-3 is acceptable ;) Solution-3 can be further improved. Instead of using static symbol table (with zero size __llvm_prf_nm symbols) to store function names for profile display and coverage mapping, the function names can be stored compressed in a non-allocatable section. The compression ratio for function name

We are now very close to push the final stage of the PGO size reduction task. Here is the updated plan going forward: 1) In this round, the format of the indexed profile data won't be unchanged. 2) there will be *no* changes in user interfaces to all profiling related tools including llvm-profdata, llvm-cov -- the change will be transparent in terms of PGO usability. 3) The implementation

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 mix of CU that are DWARF32/64. This is supported by DWARF format. With this

Hi Dennis! clang-x64-ninja-win7 fails for some time on 1. UNRESOLVED: UBSan-Standalone-x86_64::log-path_test.cc <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4522/steps/ninja%20check%201/logs/UNRESOLVED%3A%20UBSan-Standalone-x86_64%3A%3Alog-path_test.cc> this masks other new test failuers (clang modules related). Could you have a look? Yaron -------------- next

On 18.11.2020 0:20, Robinson, Paul wrote: > This is a problem only if the .debug_str section *by itself* exceeds 4GB; > are we anticipating that will happen IRL? The section is just a string > section, by itself it has no 32/64 format. > > 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

Hi! UBSan bootstrap bot fails with error report on 5 llvm-cov and llvm-profdata lit-tests: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/4526/steps/check-llvm%20ubsan/logs/stdio Also see http://llvm.org/bugs/show_bug.cgi?id=20815. The error reports look vaild: in general it's incorrect to load uint64_t, or even structures like "RawHeader" or

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