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

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D43419#1011045, @jasonmolenda wrote:

> On Darwin we load all the libraries that the binary links against pre-execution, if possible.  So I see:
>
> % lldb a.out
>  (lldb) ima li libfoo.dylib
>  [  0] 35C5FE62-5327-3335-BBCF-5369CB07D1D6 0x0000000000000000 /Volumes/ssdhome/jmolenda/k/svn/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/libfoo.dylib
>
>   /Volumes/ssdhome/jmolenda/k/svn/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/libfoo.dylib.dSYM/Contents/Resources/DWARF/libfoo.dylib
>   
>
> (lldb) br s -f foo.cpp -p BR_foo
>  Breakpoint 1: where = libfoo.dylib`Foo::Foo() + 18 at foo.cpp:4, address = 0x0000000000000f52
>  (lldb) br li
>  Current breakpoints:
>  1: source regex = "BR_foo", exact_match = 0, locations = 1
>
>   1.1: where = libfoo.dylib`Foo::Foo() + 18 at foo.cpp:4, address = libfoo.dylib[0x0000000000000f52], unresolved, hit count = 0 


So IIUC it's still unresolved because you don't know the load address of the dylib until runtime, but it at least has a location because you know the RVA in the dylib?


https://reviews.llvm.org/D43419