This is an archive of the discontinued LLVM Phabricator instance.

[target] Change target create's behavior wrt loading dependent files.
ClosedPublic

Authored by JDevlieghere on Sep 11 2018, 8:53 AM.

Details

Summary

When creating a target, lldb loads all dependent files (i.e. libs in LC_LOAD_DYLIB for Mach-O). This can be confusing, especially when two versions of the same library end up in the shared cache. It's possible to change this behavior, by specifying target create -d <target> these dependents are not loaded.

This patch changes the default behavior to only load dependent files only when the target is an executable. When creating a target for a library, it is now no longer necessary to pass -d. The user can still override this behavior by specifying the -d option. However, rather than a boolean you can now specify one of three values: default, yes, or no.

rdar://problem/43721382

Diff Detail

Repository
rLLDB LLDB

Event Timeline

I would rather not change the argument to be required if we can help it. That might break existing scripts or command files. I think if -d is specified without a value it should default to "no". Can we make the value optional?

Or add a new option that is --dependents that takes the enum and leave the --no-dependents there for compatability

I totally agree; I've left the argument name unchanged and made the argument optional. I had to change the semantics slightly (because of the negation in the argument name) but otherwise things will continue working as before (with the notable exception of the default case if no -d is specified of course).

clayborg added inline comments.Sep 12 2018, 7:39 AM
source/Commands/CommandObjectTarget.cpp
143–151

Maybe document which is the default value in one of these three strings?

  • Document default behavior.
JDevlieghere marked an inline comment as done.Sep 12 2018, 8:19 AM
shafik added a subscriber: shafik.Sep 14 2018, 10:11 AM
shafik added inline comments.
source/Commands/CommandObjectTarget.cpp
153

Should "no-dependents" be "default"?

181

Wouldn't an if/else make more sense here? I had to reread the description up top before this made sense that option_value is doing the work here.

JDevlieghere marked 2 inline comments as done.
  • Address Shafik's feedback
JDevlieghere added inline comments.Sep 17 2018, 2:11 AM
source/Commands/CommandObjectTarget.cpp
153

Only if the target is not an executable, i.e. a shared library. This is what the eLoadDependentsDefault enum value is for.

I am fine with this, Jim or Jason should ok this too just to be sure

jingham accepted this revision.Sep 19 2018, 11:39 AM

A typo and probably something copied from another test case, other than that this looks good.

packages/Python/lldbsuite/test/functionalities/target_create_deps/TestTargetCreateDeps.py
3

I don't think this is what the test actually does...

source/Commands/CommandObjectTarget.cpp
145

"executable" not "executables"

This revision is now accepted and ready to land.Sep 19 2018, 11:39 AM
This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.

This test has been failing on Windows since it was added as it doesn't build correctly. I noticed some of the tests are also disabled on Linux. Is this supposed to pass on all platforms?

Error when building test subject.
Build Command:
make VPATH=E:\_work\60\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\target_create_deps -C E:\_work\60\b\LLVMBuild\lldb-test-build.noindex\functionalities\target_create_deps\TestTargetCreateDeps.test_dependents_explicit_default_lib -I E:\_work\60\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\target_create_deps -f E:\_work\60\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\target_create_deps\Makefile all ARCH=x86_64 CC="E:\_work\60\b\LLVMBuild\Release\bin\clang.exe" 

##[error]lld-link(0,0): Error : undefined symbol: "int __cdecl a_function(void)" (?a_function@@YAHXZ)
lld-link : error : undefined symbol: "int __cdecl a_function(void)" (?a_function@@YAHXZ) [e:\_work\60\b\LLVMBuild\check-all.vcxproj]
>>> referenced by main.o:(main)
##[error]clang(0,0): Error : linker command failed with exit code 1 (use -v to see invocation)
clang : error : linker command failed with exit code 1 (use -v to see invocation) [e:\_work\60\b\LLVMBuild\check-all.vcxproj]
make: *** [a.out] Error 1

IIRC, the test is disabled on Linux not because of problems with building the test executables, but because the Linux port doesn't currently load the dependencies of an binary when it loads the binary. So the test was irrelevant on Linux, as was the feature.

Thanks. I guess the more explicit question is: which platforms is this feature (and test) applicable to? The test should be disabled on other platforms. It is already disabled on Linux because it is not applicable and it is failing to even build on Windows in its current state.

@JDevlieghere , do you expect this to work on Windows?

I wouldn't be surprised if Jonas isn't familiar enough with the Windows port to answer the question. But if you have a running lldb you can tell easily. Just do:

lldb SomeBinaryThatLoadsSharedLibraries
(lldb) image list

Do you get only SomeBinaryThatLoadsSharedLibraries, or do you get a list of the dependencies of the binary as well? If the former, then this test won't test anything for you. If the latter, then this test will test something real, and we should figure out how to get the test to build on Windows.