Done. Can you also submit it please?
Sep 23 2021
Renamed test to load_after_attach.
Sep 22 2021
PTAL. The test now passes on Linux, MacOS, and Windows.
Make test also run on Windows.
Sep 21 2021
plabath/mgorny: This change is ready for another round of review. Thanks.
Minor fix in test.
Update test to pass on MacOS
Sep 20 2021
I'm not sure all of this is relevant. I've just tried to debug a very simple (linux) executable that does a dlopens a library. If I attach to the executable before the dlopen call, lldb does not notice the new library. This patch fixes the issue. So I guess the test could be just that. You could do something similar to TestLoadUnload -- either add a new test case which attaches to that binary, or use it as inspiration to write a new test.
Minor touch-ups to the newly added test.
Add new dlopen test
Sep 16 2021
Since the meaning of m_initial_modules_added is basically "should I do a full scan through the linked list" and LoadAllCurrentModules (called from DidAttach) does a full scan, it seems to me the real bug is that this function does not set m_initial_modules_added = true. Would that fix your issue?
Yes, it does fix my bug, thanks for the suggestion. Would you like me to remove the lines 445-447 that I added, or keep them as a secondary protection (since module_sp != m_interpreter_module.lock() condition doesn't seem to be strong enough).
Added m_initial_modules_added=true into LoadAllCurrentModules.
Sep 15 2021
Sep 14 2021
Apr 22 2021
This must have been the magic glue I was missing, Thanks!
Apr 21 2021
I added a lazy-loading test. I also attempted to write a test similar to lang/cpp/static_member_type_depending_on_parent_size/TestStaticMemberTypeDependingOnParentSize.py, but I could not get it to produce an incorrect struct size (just like I couldn't reduce the reproducer).
Added functionality/lazy-loading test.
May 21 2020
I don't have commit access. Can someone submit this?
May 18 2020
I admit I don't fully understand the details of that CL and how it may interact with this one. However, I can say that I verified this CL with an Android device connected over IPv6.
May 12 2020
Where do the addresses that we're connecting to come from (the user or lldb code)? If it's lldb code, maybe we could just replace the relevant "localhost" names with an explicit ipv4 loopback address?
This is great feedback, thank you! yes, it was just two places that had "localhost" hard-coded, and just by changing it to ipv4 loopback address, I achieved the same improvement. :)
Enforce IPv4 usage only in Android code, revert non-Android changes.
May 11 2020
Update commit message.
May 7 2020
Apr 9 2020
Thanks for noticing the test breakages Pavel. I fixed the bug, and verified that the tests you mentioned pass. PTAL.
Fix broken tests.
Apr 8 2020
I don't have commit access, can someone with access commit all three approved CLs in this stack?
Apr 1 2020
Fix missing use of GetLastFile
use assertGreater instead of assertTrue(x>y)
Mar 30 2020
PTAL. Applied suggested changes, thanks for the review!
Ok, that makes kind of sense, though I am left wondering if we really need this feature, given that we have survived so long without noticing it is missing...
Am I understanding it correctly that without this patch, we would only cache the most recently accessed file (via m_last_file_sp member), and would always reload when switching to a new file?
Yes, without this patch, only the most recently accessed file is cached inside that member, and switching to a new file replaces that entry. I guess this was designed for optimizing the case where the user hits "next line" while staying in the same file. Yet, if a breakpoint on a different file is hit during that "next line" command, we trigger a reload (twice).
Mar 27 2020
Cleanup the Python test to make it a bit more readable
I added an end-to-end test to the entire use-source-cache feature in https://reviews.llvm.org/D76806
Added test that verifies end-to-end impact of
"setting set use_source_cache false" on Windows.
Mar 26 2020
- Apply code review comments from labath@
- Wipe source cache when user sets the property to false
- Also expose set/get methods for use-source-cache in SBDebugger
Applied suggestions from labath@
It's not clear to me what is the user-visible effect of this. It sounds like there should be one, but I don't know what it is...
If LLDB will cache FileSP shared pointers, there should be only one place for caching, and it's the Source File Cache, which can be enabled/disabled by the user.
User-facing effect of this change can be found in bug: llvm.org/PR45310
Applied labath@'s suggestions on test
Does this actually depend on the other patch? It looks like an independent fix we could commit separately.
This bug seems to have existed forever. Fixing it means we will have source file cache enabled for the first time. If it causes any unforeseen issues, I'd like users to have the ability to disable the cache, which is why I made this change depend on the other change.
Mar 25 2020
Add unit tests for SourceManager::SourceFileCache
I did not see any existing tests that validate setting/reading of properties. Can you point to me if you know any that exists?
fix link warning
- Remove m_last_file_sp from SourceManager
Adding 3rd commit to diff
I don't have commit access.
- Added comments to Android-specific test cases, as suggested by labath@.
- Reformatted lines that exceeded 80 chars.
Mar 24 2020
Added unit tests.