summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2018-12-14 22:44:46 +0000
committerDavid Blaikie <dblaikie@gmail.com>2018-12-14 22:44:46 +0000
commit560ff3559278cff3ecd3ad9d61b6ad4ee697e298 (patch)
treea9c20f582711f6355014964371b5bae28929701c /lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
parent1b9c746034f15aca6039d2369068346f09a2d62f (diff)
downloadbcm5719-llvm-560ff3559278cff3ecd3ad9d61b6ad4ee697e298.tar.gz
bcm5719-llvm-560ff3559278cff3ecd3ad9d61b6ad4ee697e298.zip
DebugInfo: Avoid using split DWARF when the split unit would be empty.
In ThinLTO many split CUs may be effectively empty because of the lack of support for cross-unit references in split DWARF. Using a split unit in those cases is just a waste/overhead - and turned out to be one contributor to a significant symbolizer performance issue when global variable debug info was being imported (see r348416 for the primary fix) due to symbolizers seeing CUs with no ranges, assuming there might still be addresses covered and walking into the split CU to see if there are any ranges (when that split CU was in a DWP file, that meant loading the DWP and its index, the index was extra large because of all these fractured/empty CUs... and so was very expensive to load). (the 3rd fix which will follow, is to assume that a CU with no ranges is empty rather than merely missing its CU level range data - and to not walk into its DIEs (split or otherwise) in search of address information that is generally not present) llvm-svn: 349207
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud