[PATCH] D42297: [DebugInfo] Basic .debug_names dumping support

Pavel Labath via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 24 02:56:46 PST 2018


labath marked 14 inline comments as done.
labath added a comment.

In https://reviews.llvm.org/D42297#985510, @JDevlieghere wrote:

> Looking at how we currently query the accelerator tables for names, I wonder if we'd be able to share the `ValueIterator` so that we can move the `equal_range` method into the base class. At first sight it looks feasible as most of the work is done in the `equal_range` function itself, which can potentially be different between the two tables. Pavel, what do you think?


I was hoping to leave that for a separate patch. The main reason the ValueIterator class cannot be used out-of-the-box is because it assumes the accelerator table is homogeneous, but in the dwarf5 case, each abbreviation can describe a different set of index attributes. So we will need to come up with a more generic iterator for the dwarf tables (and that one can then be used for the apple tables as well).  (And even the tiny bit of parsing that happens in the iterator (`Next()` function) is incorrect for dwarf5).



================
Comment at: lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp:25
 
+static std::string formatEnum(StringRef (*StringFn)(unsigned), StringRef Type, unsigned Value) {
+  std::string Str = StringFn(Value);
----------------
aprantl wrote:
> Would it make more sense for these functions to take a raw_ostream as first argument instead of creating a temporary std::string?
I did it to streamline the usage (just << everything into OS). But I guess the same thing can be achieved by having formatXXX return a struct and defining an operator<< for that struct.


Repository:
  rL LLVM

https://reviews.llvm.org/D42297





More information about the llvm-commits mailing list