[Lldb-commits] [PATCH] D43419: Fix TestBreakpointInGlobalConstructor for Windows

[Jim Ingham via lldb-commits]

We don’t parse libraries beyond getting sections until we look for symbols, this doesn’t seem to slow startup noticeably, and since I find it super useful especially for a program like lldb, where the driver has very little code in it and most of the functionality is in libraries, I’m happy with the tradeoff.

But I don’t think we should require all platforms to do this, nor is it expected to be exact (for instance, the darwin dynamic loader plugin doesn’t track setting environment variables in the run-args, re-calculating the loaded libraries based on new DYLD_LIBRARY_PATH variables…  So the tests should be flexible and not require this.  I think having a special value for num_locations is fine.

We probably should add some tests that explicitly test this for platforms that do support the feature, I think we are only testing it by accident now.

Jim


> On Feb 20, 2018, at 9:37 AM, Adrian McCarthy via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> amccarth added a comment.
> 
> I have reservations about making the debugger try to pre-locate the modules and their PDBs before those modules are actually loaded.  For a few reasons.
> 
> (1) On Windows, module resolution is complex.  Search paths, the safe search path, manifests, the side-by-side cache, dynamic library link redirection (.exe.local), Windows API sets, etc.  It got to the point that Microsoft dropped support for the venerable DependencyWalker tool (though there is an open source community trying to keep it alive).  That's a lot of logic to bake into the debugger (and to create tests for), and the cost of getting it wrong is that we think your breakpoint will resolve when actually it won't.
> 
> (2) A typical program depends directly and indirectly on many DLLs.  Even with lazy-evaluation, trying to apply all the rules in 1 (which must be done serially) to locate all of the dependents seems like a lot of unnecessary work on startup.
> 
> (3) It's different than how all the debuggers on Windows work, which might be mildly surprising to users.
> 
> If there's a strong will to head down this path, I think that'll be a separate effort than my getting this test working again in the short term.  So I think I'll do something less invasive along the lines of Pavel's suggestion to get this test working.  Stay tuned.
> 
> 
> https://reviews.llvm.org/D43419
> 
> 
>