search for: libfinddebuginfo

...like reserving an LLVM vendor-specific DWARF opcode/attribute/whatever and then stick a blob of data in there. Presumably we have code somewhere in LLDB that is "here's a binary, find debug info for it", and in principle we could factor out that code and lift it into an LLVM library (libFindDebugInfo) that llvm-profdata could use. > - Size contributed by __llvm_prf_names sections: 327.46 MB > \_ Just within clang: 106.76 MB > > => Space wasted within the clang binary: 447.24 MB > > Running an instrumented clang binary triggers a 143MB raw profile write >...

...LVM vendor-specific DWARF opcode/attribute/whatever and then > stick a blob of data in there. Presumably we have code somewhere in LLDB > that is "here's a binary, find debug info for it", and in principle we > could factor out that code and lift it into an LLVM library > (libFindDebugInfo) that llvm-profdata could use. > > >> - Size contributed by __llvm_prf_names sections: 327.46 MB >> \_ Just within clang: 106.76 MB >> >> => Space wasted within the clang binary: 447.24 MB >> >> Running an instrumented clang binary triggers...

...fic DWARF opcode/attribute/whatever and then >> stick a blob of data in there. Presumably we have code somewhere in LLDB >> that is "here's a binary, find debug info for it", and in principle we >> could factor out that code and lift it into an LLVM library >> (libFindDebugInfo) that llvm-profdata could use. >> >> >>> - Size contributed by __llvm_prf_names sections: 327.46 MB >>> \_ Just within clang: 106.76 MB >>> >>> => Space wasted within the clang binary: 447.24 MB >>> >>> Running an in...

Problem ------- Instrumentation for PGO and frontend-based coverage places a large amount of data in object files, even though the majority of this data is not needed at run-time. All the data is needlessly duplicated while generating archives, and again while linking. PGO name data is written out into raw profiles by instrumented programs, slowing down the training and code coverage workflows.