[Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Can we change DebugMacroEntry to contain a std::unique_ptr<DebugMacro> instead of a shared pointer? This would save us one full pointer in each DebugMacroEntry.

That is the only change I would like to see.

The expand on the benefit of having two structs like DebugMacroEntryStorage would be you can store it very efficiently with bitfields and store the macros inside DebugMacro as a vector of DebugMacroEntryStorage structs. But the API from DebugMacro could that gets an entry at index could return the bigger fatter version of this. The two structs below would be an example:

We store macro entries inside DebugMacro as:

  class DebugMacroEntryStorage
  {
      EntryType m_type:3;
      uint32_t m_line:29;
      uint32_t m_file;
      ConstString m_str;
      DebugMacrosSP m_debug_macros_sp;
  };

But the function:

  DebugMacroEntry
  GetMacroEntryAtIndex(const size_t index) const

would return something like:

  class DebugMacroEntryStorage
  {
      CompileUnit *m_comp_unit;
      EntryType m_type;
      uint32_t m_line;
      FileSpec m_file;
      ConstString m_str;
      DebugMacrosSP m_debug_macros_sp;
  };

We would resolve the "m_file" into a FileSpec for public consumption by getting the correct file from the compile unit's support files FileSpecList and not compress the storage and also fill in the m_comp_unit if needed.

This doesn't need to be done, but this is what I was thinking. I did this in LineTable.h where I store line entries as a lldb_private::LineTable::Entry objects, but I hand them out to clients as lldb_private::LineEntry objects.


http://reviews.llvm.org/D15437