This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL325704: Fix TestBreakpointInGlobalConstructor for Windows
(authored by amccarth, committed by ).
Herald added a subscriber
amccarth updated this revision to Diff 135272.
amccarth added a comment.
Per Pavel's suggestion, change special value to mean don't check the number of
locations found.
https://reviews.llvm.org/D43419
Files:
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/T
labath added a comment.
Yes, regardless of the target platform, if you specify num_locations = -2, then
we just don't check the number of locations.
https://reviews.llvm.org/D43419
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://li
amccarth added a comment.
By unconditional, do you mean allowing any value for `out_num_locations` in
these cases? I'm happy to do that, but I'm not sure if I've understood you
correctly.
https://reviews.llvm.org/D43419
___
lldb-commits mailing l
labath added a comment.
I was actually thinking of making this unconditional. It makes the behaviour
easier to understand and this test really does not care about whether the
libraries were resolved statically or not.
I'm with Jim that we should make targeted tests for that functionality.
htt
amccarth added a comment.
In https://reviews.llvm.org/D43419#1013559, @jingham wrote:
> At some point we should introduce "platformCapacities" so that you could do:
>
> if not test.getPlatformCapacities("preload-dylibs"):
>
>
> so we are testing specific features not the whole platform.
Ye
amccarth updated this revision to Diff 135124.
amccarth added a comment.
Wrapped the modified docstring.
https://reviews.llvm.org/D43419
Files:
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
lldb/packages/Python/lldbsu
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
At some point we should introduce "platformCapacities" so that you could do:
if not test.getPlatformCapacities("preload-dylibs"):
so we are testing specific features not the whol
amccarth updated this revision to Diff 135120.
amccarth added a comment.
Added new special value to accommodate the fact that Windows may postpone
resolving the breakpoints for DLLs that aren't yet loaded.
https://reviews.llvm.org/D43419
Files:
lldb/packages/Python/lldbsuite/test/functional
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
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
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
jingham added a comment.
The debug info is parsed only when needed. So for breakpoints, it will get
parsed when the breakpoint is set. That's one good use of "break set -s
" BTW, it will limit the debug info read in to just the library
you expect to find the symbol in.
https://reviews.llvm.
jingham added a comment.
If you want to avoid loading dependent libraries, you can use the "-d" flag to
"target create". This is sometimes handy, but shouldn't be the default
behavior.
https://reviews.llvm.org/D43419
___
lldb-commits mailing list
zturner added a comment.
I guess on the other hand, it's reasonable to assume that if you've set a
breakpoint somewhere, you're more likely than not to need it since you probably
had a reason for setting it. Is the debug info parsed when the executable is
loaded, or when the breakpoint is set?
zturner added a comment.
I guess one advantage to delaying it is that the debug info for the dynamic
library could be large and slow to parse, and you don't know if you're even
going to need it until you hit the breakpoint. So by delaying the resolution
even to File address, you postpone parsi
jingham added a comment.
It is really handy to see the pre-load libraries in lldb, it means you can do
"source list" to make sure the breakpoints you are planning to set are where
you expect them to be, and tab completion can help you set breakpoints pre-run,
etc. So if you can do this, your u
zturner added a comment.
I'm not sure how hard it would be, but it would be better if we could do the
same thing on Windows, for consistency of behavior. In principle it's
straightforward, just scan through the IAT and load all of the imported
modules. Probably the DynamicLoaderWindows plugin
amccarth added a comment.
OK, so my fix is too simplistic. I'll have to (1) make LLDB on Windows also
attempt to pre-load the DLLs, (2) make the test use platform-specific
expectations, or (3) use a looser expectation. I'll give it some thought over
the weekend.
https://reviews.llvm.org/D43
jasonmolenda added a comment.
Yeah, it has a location because we're resolved it to a File address
(section+offset), and when the dylib actually gets loaded we'll resolve that to
a load address and insert the breakpoint instruction.
https://reviews.llvm.org/D43419
___
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 0x00
jasonmolenda added a comment.
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 0x
/Volumes/ssdhome/jmolenda/k/svn/lldb/packages/Python/lldbs
zturner added a reviewer: labath.
zturner added a comment.
What's the behavior on other platforms? When you set a breakpoint in a shared
library before you've run the program, shouldn't it still be unresolved, in
which case this test should have failed on those platforms too?
https://reviews.
amccarth created this revision.
amccarth added a reviewer: jasonmolenda.
Herald added a subscriber: sanjoy.
This test was failing on Windows because it expected the breakpoint in the
dynamic library to be resolved before the process is launched. Since the DLL
isn't loaded until the process is lau
24 matches
Mail list logo
