labath requested changes to this revision. labath added a comment. This revision now requires changes to proceed.
Yeah, setting this to zero would break other platforms that are able to locate shared libraries before running the executable. On linux, we try to locate them as well, but it's kind of on a best-effort basis -- it's quite hard to figure out what library will get loaded with absolute precision, as it can e.g. depend on the value of LD_LIBRARY_PATH env var that you run the process with (and you don't know that until the actual "process launch" command). In fact, it wouldn't be hard to come up with examples where this static resolution finds the wrong library. So, it sounds to me like we do need a special flag for "zero or more" breakpoint locations for tests which don't care about this behavior such as this one. Maybe num_expected_locations=-2 (I think we should leave "0" meaning "exactly zero", as that can be useful in some situations). In fact I know of at least one other test that could use something like this (I've had to disable some tests in TestLoadUnload on linux because the out-of-tree build caused the automatic library lookup to not work). Of course being able to resolve DLL dependencies statically like other platforms would be nice, but that's quite orthogonal to this what this test is doing. (Here the purpose is to check that we set the breakpoint early enough -- before the global constructor executes). https://reviews.llvm.org/D43419 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
