This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Implement SymbolFile::CopyType
ClosedPublic

Authored by augusto2112 on Jan 18 2023, 12:28 PM.

Details

Summary

SymbolFiles should be the only point of creation of Types to ensure
that they aren't destroyed prematurely by keeping them in the
SymbolFile's TypeList. This patch hides the copy constructor of Types,
and adds a new CopyType function to SymbolFile, so Types can still be
copied safely.

Diff Detail

Event Timeline

augusto2112 created this revision.Jan 18 2023, 12:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2023, 12:28 PM
augusto2112 requested review of this revision.Jan 18 2023, 12:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2023, 12:28 PM

We don't allow types to be copied into another SymbolFile. There is a strict rule in LLDB that SymbolFile objects only create types from their own data. There are many reasons we don't want this:

  • Type objects have a m_symbol_file which points to the SymbolFile that created it. This pointer can and will go bad if the original symbol file is freed.
  • Type objects have a symbol context member variable ( "SymbolContextScope *m_context;"), same issue as above
  • Type objects might have a valid encoding type member variable ("Type *m_encoding_type;") that is non NULL that points to a type that is owned by the original symbol file
  • Type objects might have a encoding User ID and encoding type that point to the original symbol file ( lldb::user_id_t m_encoding_uid = LLDB_INVALID_UID; EncodingDataType m_encoding_uid_type = eEncodingInvalid;) and the user_id_t only makes sense in the original encoding type.

@clayborg the intended usage here is to create a copy of the type in the same symbol file. I could add a sanity check that makes sure we're not creating a copy of something that isn't in the symbol file's type list in debug mode. Would that be enough?

@clayborg the intended usage here is to create a copy of the type in the same symbol file. I could add a sanity check that makes sure we're not creating a copy of something that isn't in the symbol file's type list in debug mode. Would that be enough?

When would you need to copy a type that is already in SymbolFile::m_type_list?

@clayborg we have one instance downstream where we need to keep two types around. One for the original type and one for a slightly modified one (here). This patch is just a way to make sure any new type we copy is inserted in the type list as well.

clayborg requested changes to this revision.Jan 19 2023, 5:15 PM

Gotcha, makes sense now. Thanks for the extra info. We do need to make sure the m_symbol_file values match and return an empty TypeSP if they don't. Once that is done, this is good to go.

lldb/include/lldb/Symbol/SymbolFile.h
527

We have to check if other_type has the same symbol file and return nothing if it doesn't match.

This revision now requires changes to proceed.Jan 19 2023, 5:15 PM

Added check for same symbol file

This revision was not accepted when it landed; it landed in state Needs Review.Jan 20 2023, 1:02 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.