This is an archive of the discontinued LLVM Phabricator instance.

DwarfAccelTable: Make Dwarf accelerator table generic.
Needs RevisionPublic

Authored by friss on Mar 10 2015, 11:01 AM.

Details

Summary

Today, the fields dumped in the accelerator tables are hardcoded to
the 2 variants that LLVM produces. llvm-dsymutil would like to reuse
that code, but needs to ouptut another variant.

This patch makes the DwarfAccelTable generic and the emitted data
is actually derived from the list of atoms passed to its constructor.
In order not to waste memory (this structure can grow very big on
huge programs), it allocates memory for the atom contents right
after the HashDataContents struct and uses memcpy to access them.

The only hardcoded thing is that the first atom must be a DIE offset.
has the table is always used as a map from name to DIEs, this makes
sense.

From the emitted code point of view, the patch is actually NFC, we
rely on the existing tests to prove that the patch doesn' break
anything.

Diff Detail

Event Timeline

friss updated this revision to Diff 21605.Mar 10 2015, 11:01 AM
friss retitled this revision from to DwarfAccelTable: Make Dwarf accelerator table generic..
friss updated this object.
friss added reviewers: dblaikie, echristo, aprantl.
friss added a subscriber: Unknown Object (MLST).
echristo edited edge metadata.Mar 10 2015, 11:08 AM

What other variant are you going to output? We did recently standardize a new (but closely related) variant as part of DWARF5.

-eric

friss added a comment.Mar 14 2015, 9:14 AM

Hadn't seen your message, sorry for the delay in replying. It turns out lldb uses different atoms (as produced by dsymutil) than the one we currently hardcode. The only table having additional atoms is the types table. In addition to the DIE offset, LLVM emits:

  • DW_ATOM_die_tag = 3u // A tag entry.
  • DW_ATOM_type_flags = 4u // Set of flags for a type.

The type flags are always hardcoded to 0 (I plan to remove this field as it serves no purpose). LLDB on the other hand has these atoms definition:

  • eAtomTypeTag = 3u, // DW_TAG_xxx value,
  • eAtomTypeNameFlags = 4u, // Flags from enum NameFlags
  • eAtomTypeTypeFlags = 5u, // Flags from enum TypeFlags
  • eAtomTypeQualNameHash = 6u // A 32 bit hash of the full qualified name

And it actually doesn't use TypeNameFlags. but it uses the last 2.

I'm wondering if Adrian hasn't planed a new use of an accelerator table that would require yet another variant of atom combinations for his module debugging work.

echristo accepted this revision.Mar 31 2016, 2:46 PM
echristo edited edge metadata.

Adding the atoms explicitly in DwarfDebug is a little weird rather than just setting the format when you create the tables. Any reason why you want to do it there?

-eric

This revision is now accepted and ready to land.Mar 31 2016, 2:46 PM
echristo requested changes to this revision.Mar 31 2016, 2:47 PM
echristo edited edge metadata.
This revision now requires changes to proceed.Mar 31 2016, 2:47 PM

(Honestly it's probably fine either way, but I'd like the question answered first if it's not too much of a problem. Thanks!)

-eric