llvm-project.git/lldb/test/API/functionalities/rerun_and_expr_dylib/main.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb][Test] TestRerunAndExprDylib.py on Linux: dlclose solib to force destruction module 2022-12-05T18:14:26+00:00 Michael Buch michaelbuch12@gmail.com 2022-12-05T18:12:56+00:00 e31160155e484414db9177806ae9f0840c985b49 Previously we didn't properly trigger the destructor of the `lldb_private::Module` backing `libfoo.so`. So the newly rebuilt version wouldn't actually be loaded on a program re-run. The test expects the fresh module to be loaded. 
Previously we didn't properly trigger the destructor of
the `lldb_private::Module` backing `libfoo.so`. So the newly
rebuilt version wouldn't actually be loaded on a program re-run.
The test expects the fresh module to be loaded.
Reland "[lldb][Target] Flush the scratch TypeSystem when owning lldb_private::Module gets unloaded" 2022-12-05T16:57:42+00:00 Michael Buch michaelbuch12@gmail.com 2022-11-25T14:45:09+00:00 e1edcf7d14c126b9ebd2a77fcd9041d056cce64a This relands commit `71f3cac7895ad516ec25438f803ed3c9916c215a` Fixes LLDB Linux bots and improves TypeSystem flushing for shared libraries. Differential Revision: https://reviews.llvm.org/D138724 
This relands commit `71f3cac7895ad516ec25438f803ed3c9916c215a`

Fixes LLDB Linux bots and improves TypeSystem flushing for shared libraries.

Differential Revision: https://reviews.llvm.org/D138724
Revert "[lldb][Target] Flush the scratch TypeSystem when owning lldb_private::Module gets unloaded" 2022-12-02T14:12:41+00:00 Michael Buch michaelbuch12@gmail.com 2022-12-02T14:12:41+00:00 71f3cac7895ad516ec25438f803ed3c9916c215a This reverts commit 4df11394a10b3b15d2fb9bde8b831cf68785aa45. 
This reverts commit 4df11394a10b3b15d2fb9bde8b831cf68785aa45.
[lldb][Target] Flush the scratch TypeSystem when owning lldb_private::Module gets unloaded 2022-12-02T10:52:41+00:00 Michael Buch michaelbuch12@gmail.com 2022-11-25T14:45:09+00:00 4df11394a10b3b15d2fb9bde8b831cf68785aa45 **Summary** This patch addresses #59128, where LLDB would crash when evaluating importing a type that has been imported before into the same target. The proposed solution is to clear the scratch AST (and associated persistent variables, `ClangASTImporter`, etc.) whenever a module that could've owned one of the stale `TypeSystem`s gets unloaded/destroyed. Details: 1. The first time we evaluate the expression we import the decl for Foo into the Targets scratch AST context (lives in m_scratch_type_system_map). During this process we also create a ClangASTImporter that lives in the ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking structures which reference the source AST that the decl got imported from. This importer also gets re-used for all calls to DeportType (which we use to copy the final decl into the Targets scratch AST). 2. Rebuilding the executable triggers a tear-down of the Module that was backing the ASTContext that we originally got the Foo decl from (which lived in the Module::m_type_system_map). However, the Target’s scratch AST lives on. 3. Re-running the same expression will now create a new ASTImporterDelegate where the destination TranslationUnitDecl is the same as the one from step (1). 4. When importing the new Foo decl we first try to find it in the destination DeclContext, which happens to be the scratch destination TranslationUnitDecl. The `Foo` decl exists in this context since we copied it into the scratch AST in the first run. The ASTImporter then queries LLDB for the origin of that decl. Using the same persistent variable ClangASTImporter we claim the decl has an origin in the AST context that got torn down with the Module. This faulty origin leads to a use-after-free. **Testing** - Added API test Differential Revision: https://reviews.llvm.org/D138724 
**Summary**

This patch addresses #59128, where LLDB would crash when evaluating
importing a type that has been imported before into the same target.
The proposed solution is to clear the scratch AST (and associated
persistent variables, `ClangASTImporter`, etc.) whenever a module that
could've owned one of the stale `TypeSystem`s gets unloaded/destroyed.

Details:
1. The first time we evaluate the expression we import the decl for Foo into the Targets scratch AST
   context (lives in m_scratch_type_system_map). During this process we also create a ClangASTImporter
   that lives in the ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking
   structures which reference the source AST that the decl got imported from. This importer also gets
   re-used for all calls to DeportType (which we use to copy the final decl into the Targets scratch AST).
2. Rebuilding the executable triggers a tear-down of the Module that was backing the ASTContext that
   we originally got the Foo decl from (which lived in the Module::m_type_system_map). However, the Target’s scratch AST lives on.
3. Re-running the same expression will now create a new ASTImporterDelegate where the destination TranslationUnitDecl is
   the same as the one from step (1).
4. When importing the new Foo decl we first try to find it in the destination DeclContext, which happens to be
   the scratch destination TranslationUnitDecl. The `Foo` decl exists in this context since we copied it into
   the scratch AST in the first run. The ASTImporter then queries LLDB for the origin of that decl. Using the
   same persistent variable ClangASTImporter we claim the decl has an origin in the AST context that got torn
   down with the Module. This faulty origin leads to a use-after-free.

**Testing**

- Added API test

Differential Revision: https://reviews.llvm.org/D138724