Allow host platform to use sdk sysroot directory option when resolving shared modules

[trevorj]

Summary

Hi! I noticed recently that when using the host platform with an sdk sysroot set, modules are not resolved using a path prefixed by the set sysroot path.

Backstory: I'm trying to debug production coredumps on a development machine using a sysroot folder tree that contains *all* of the required shared objects required to run the binary.

An example sysroot tree would be:

/tmp/debug-[snip]-coredump.1869466.bL8C/sysroot
├── this_is_a
│   └── dummy
│       └── path
│           └── libsomething.so
└── lib64
│       └── libother.so

In gdb, I use this via set sysroot /path/to/sysroot.
In LLDB, I assume I should do something like platform select host -S /path/to/sysroot.

After doing either of these I would expect the attempted paths for loading shared objects will be prefixed by the configured sysroot.
Unfortunately, when using the host platform, it currently ignores the sysroot configuration option when trying to load shared objects.
This breaks the sysroot setting on the host platform.

I believe these lines would be okay to remove because it falls back to normal resolution.

If I'm just doing something wrong let me know too :)
Let me know if you want me to clarify anything!

Thanks!

(Can happily add a test, but I wanted to make sure my approach was valid from the experts (ie you!) beforehand)

[JDevlieghere]

Hey Trevor,

Thank you for your patch. Please include as much context as possible when uploading a patch [1]. It makes it a lot easier for the reviewers to see the surrounding code.

Could you please describe the issue you're seeing in a little more detail? Preferably with an example or steps to reproduce, even better if it's in the form of a test, which we'll definitely need for a change like this.

[1] https://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch

[trevorj]

@JDevlieghere Sure I can provide more context, let me know if you want me to clarify anything!

I updated the summary with more information, let me know if I can help in any other way.

[labath]

In LLDB, I assume I should do something like platform select host -S /path/to/sysroot

I /think/ you're expected to do platform select remote-whatever -S /path/to/sysroot

[clayborg]

What Pavel said should work (there is always a "remote-<platform>" name for everything like "remote-linux" even if you are on linux to start with. The host platform assumes that everything comes from the current host.

That being said we also have a few ways to make this work without any changes:

(lldb) platform select remote-linux -S /tmp/debug-[snip]-coredump.1869466.bL8C/sysroot
(lldb) target create --core ...

Not sure if this would work:

(lldb) setting set target.exec-search-paths /tmp/debug-[snip]-coredump.1869466.bL8C/sysroot
(lldb) setting set target.debug-file-search-paths /tmp/debug-[snip]-coredump.1869466.bL8C/sysroot
(lldb) target create --core ...

The first way is the best way I believe.

[trevorj]

@clayborg The problem with the second variation is it doesn't prefix the path, it just looks for shared objects of the same basename in the folders you specify.

I thought that remote-linux requires a server? Maybe it doesn't and I've just had the wrong mental model of what remote is :)

[clayborg]

In D131212#3708142, @trevorj wrote:

@clayborg The problem with the second variation is it doesn't prefix the path, it just looks for shared objects of the same basename in the folders you specify.

Yes, that is correct now that I think about it.

I thought that remote-linux requires a server?

It does not. You _can_ connect to a remote server if you want to, but you don't have to. Many workflows need to select a remote platform to let LLDB know how to locate files when doing symbolication and when loading core files, so you should just be able to use the workflow I suggested that was based on Pavel's comments. Does that work for you?

[trevorj]

It does not. You _can_ connect to a remote server if you want to, but you don't have to. Many workflows need to select a remote platform to let LLDB know how to locate files when doing symbolication and when loading core files, so you should just be able to use the workflow I suggested that was based on Pavel's comments. Does that work for you?

Trying it out, that worked to load my shared objects! I was completely wrong about what remote-linux was then, sorry!

Curious, why does the host platform support being sent a sysroot parameter when selecting it if it doesn't use it?

[labath]

In D131212#3708426, @trevorj wrote:

It does not. You _can_ connect to a remote server if you want to, but you don't have to. Many workflows need to select a remote platform to let LLDB know how to locate files when doing symbolication and when loading core files, so you should just be able to use the workflow I suggested that was based on Pavel's comments. Does that work for you?

Trying it out, that worked to load my shared objects! I was completely wrong about what remote-linux was then, sorry!

Curious, why does the host platform support being sent a sysroot parameter when selecting it if it doesn't use it?

Because noone made it not do that? :)

I think it would be a good patch to make that command produce an error.

lldb/source/Target/Platform.cpp

     const ModuleSpec &module_spec, Process *process, ModuleSP &module_sp,
     const FileSpecList *module_search_paths_ptr,
     llvm::SmallVectorImpl<lldb::ModuleSP> *old_modules, bool *did_create_ptr) {
-  if (IsHost())
-    return ModuleList::GetSharedModule(module_spec, module_sp,
-                                       module_search_paths_ptr, old_modules,
-                                       did_create_ptr, false);
-
   // Module resolver lambda.
   auto resolver = [&](const ModuleSpec &spec) {
     Status error(eErrorTypeGeneric);