[Lldb-commits] [PATCH] D138724: [lldb][Target] Flush the scratch TypeSystem when process gets deleted

[Michael Buch via Phabricator via lldb-commits]

Michael137 added a comment.

In D138724#3988715 <https://reviews.llvm.org/D138724#3988715>, @Michael137 wrote:

> In D138724#3988318 <https://reviews.llvm.org/D138724#3988318>, @labath wrote:
>
>> I just found out that this test (the non-shared-library version) fails on linux if the executable is built with `-no-pie` (which is the default if the `CLANG_DEFAULT_PIE_ON_LINUX` option is not set, which happened to be the case for my build). I think the important fact here is that a PIE ELF executable gets its `e_type` field set to `ET_DYN`, which causes lldb to identify it as a shared library. However, it is not clear to me why would that matter in this case...
>
> From what I can tell the main difference with `no-PIE` executable is that `Target::ModulesDidUnload` doesn't get called when relaunching the process. Whereas in the `PIE` case we do:
>
>   PlatformPOSIX::DebugProcess
>   -> Process::Launch
>     -> DynamicLoaderPOSIXDYLD::DidLaunch
>       -> DynamicLoader::GetTargetExecutable
>         -> Target::SetExecutableModule
>           -> Target::ClearModules
>             -> Target::ModulesDidUnload

Ah I may have spotted the issue (but yet to confirm).

Currently, when relaunching an executable, the `DynamicLoader` plugin does this:

  ModuleSP DynamicLoader::GetTargetExecutable() {
          ...
          if (executable.get() != target.GetExecutableModulePointer()) {        
            // Don't load dependent images since we are in dyld where we will   
            // know and find out about all images that are loaded
            target.SetExecutableModule(executable, eLoadDependentsNo);          

In `target.GetExecutableModulePointer` we return the pointer the first module of type `eTypeObjectFile`, which with `no-pie` will not be `a.out`, so then we just return the first module in `m_images`. In the `no-pie` case we don't take this branch and maybe this is why. Will check shortly


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138724/new/

https://reviews.llvm.org/D138724