[PATCH] D106624: [WIP][DWARF] Don't process .debug_info relocations for DWO Context

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

70GB seems like quite a bit - do you have a description of the scenario (ideally something reproducible - like "build clang at this revision with these flags and run these commands & the memory profile looks like this")? I'm guessing this is running llvm-symbolizer on a large Split DWARF input (without a DWP file, so using loose/separate .dwo files) and passing in many addresses to symbolize (forcing many of those .dwo files to be loaded)? I'd be curious to know exactly which data structures, etc,

Could this be tested - with, say, an invalid relocation or something, demonstrating that relocations are no longer applied? (I guess we never applied them to the .dwo sections, right? But we'd parse them for the non-dwo sections in the .dwo file (eg, when using split-dwarf=single?), so I'm not sure if there's any kind of invalidity we could put in the relocation section of the non-dwo sections - oh, I see we try to apply the relocations early, so maybe there is some invalidity that would expose this? not perfect, but maybe a little motivating/demonstrating.



================
Comment at: llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:1739
+      if (RelocatedSection == Obj.section_end() ||
+          (IsDWOContext && !Name.contains(".dwo")))
         continue;
----------------
How come this tests both these properties? I guess there's some case where `IsDWOContext` is inadequate/isn't correct and the file extension test is needed? What's that case?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106624/new/

https://reviews.llvm.org/D106624