This patch is an effort to make the DwarfAccelTable more generic so they
can be reused by the dsymutil implementation, where we need to support
different atoms for LLDB:
eAtomTypeTypeFlags = 5u, // Flags from enum TypeFlags eAtomTypeQualNameHash = 6u // A 32 bit hash of the full qualified name
Similar to some patches from Fred in the past, my goal was to make the
DwarfAccelTable generic and the emitted data is actually derived from
the list of atoms passed to its constructor. For this purpose I have
added a callback function to the interface. This callback function can
is used to generate a value for a combination of row (HashDataContents)
and column (Atom).
I believe this approach provides the best trade-off between making the
table more generic while still building on the current, proven
implementation.
As discussed on the mailing list
(http://lists.llvm.org/pipermail/llvm-dev/2018-January/120499.html) we
want to bring DWARFv5 accelerator tables to LLVM. The goal is to share
as much logic as possible between the two implementation. With that in
mind, I believe it's beneficial to have llvm-dsymutil use the current
implementation, as to ensure that the future design supports this use
case down the line.
From the emitted code point of view, the patch is actually NFC, we rely
on the existing tests to prove that the patch doesn't break anything.
Do we need the HashDataContents struct if it is just a DIE* wrapper? I am not sure if there is anything that we would want to emit that cannot extracted from a DIE pointer by a suitable DataForAtomFunction callback...