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

[Alexander Yermolovich via Phabricator via llvm-commits]

ayermolo added a comment.

In D106624#2900158 <https://reviews.llvm.org/D106624#2900158>, @dblaikie wrote:

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

Sorry, forgot to mention. This is regarding BOLT with -update-debug-sections turned on using it on an internal service build with -O2 mode and -g debug information. Without ThinLTO.
Right we are building it with -split-dwarf=single so the .dwo sections are in the .o file not in .dwo. Actually with -split-dwarf=split this problem would not manifest because it will only have .dwo sections.
I attached a screen shot with stack trace and memory consumption. Basically I am going through Skeleton CUs and creating DWARFUnits for non-skeleton CUs that are in .o files. This goes through getDWOContext and eventually calls DWARFObjInMemory. It doesn't know for what purpose it is invoked so it goes through all the debug sections. Including the regular one that are in .o file. Which we don't really care about I think since we are creating Context for DWO. If relocations for that exist then sure we should apply them (is that even a thing?), but for regular debug section, when creating context for DWO, I don't think it's necessary.
Thus a check for a flag and for .dwo. If it's true then we only care about .dwo sections.
F18096137: boltMemoryConsumption.png <https://reviews.llvm.org/F18096137>


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106624