labath requested changes to this revision. labath added a comment. Hmm... now that I actually have read what this patch does, I am starting to think that this is not a good idea:
- on linux it was possible to load an executable via "dlopen", at least until last year, when it was (partially?) disabled by https://patchwork.ozlabs.org/patch/1055380/ - opening an executable via dlopen still works on a mac (10.15.1 Catalina), though I'm not sure how much it's officially supported - on windows LoadLibrary <https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya> is explicitly documented to be able to open .exe files Now given that the effect of `SetExecutableModule` is to completely destroy the information about other loaded shared libraries, and that dlopening an exe works (for some definition of "works") on all major platforms, I don't think calling this function in response to a module being added (e.g. because of dlopen) is reasonable. I think we need to go back to the drawing board and handle this at a different level -- either by changing lldb-vscode, or some of the higher-level launching logic. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70847/new/ https://reviews.llvm.org/D70847 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
