[PATCH] D102219: Optimize GSymCreator::finalize.

[Greg Clayton via Phabricator via llvm-commits]

clayborg added a comment.

In D102219#2755080 <https://reviews.llvm.org/D102219#2755080>, @simon.giesecke wrote:

> FWIW, and unrelated to this patch: processing other, more complex gcc-built binaries, e.g. clang, produces a lot of the other warnings (with and without the patch). Not sure if that's concerning.

This is par for the course. Everyone produces debug info and the debug info usually has some issues. llvm-gsymutil is merely pointing out issues it runs into when parsing this information. llvm-gsymutil is also smart enough to ignore debug info that should have been stripped, but can't. This stems from the fact that linkers don't know anything about DWARF and they like to just concatenate all DWARF sections from each .o file and relocate any addresses that were not stripped. This means for debug info that had no relocations will still remain in the DWARF. For those functions, they typically get their addresses set to zero or -1. llvm-gsymutil knows to ignore these when it calls GsymCreator::SetValidTextRanges(...) after it parses the sections of the object file. Any function infos whose start address doesn't start in a valid text range will be omitted.

You can also build "llvm-dwarfdump" and then run it using the "--verify" option. It will point out any issues that exist in the DWARF.

So warnings are normal because there are many issues with the DWARF produced by all compilers and linkers. Some are worse than others, but in general we try to work around these issues and still produce a GSYM. Link Time Optimizations (LTO) also tends to outline many functions and also combine functions with common code, so you can have multiple DWARF functions point to the same address. If the line entries are all the same and the function name matches, that is easily detected, but sometimes we have templated code that is inlined, like std::shared_ptr::~shared_ptr<T>() that ends up creating the same code for multiple different instances and they get combined even though the line tables would look different.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102219