Jun 1 2021
May 17 2021
May 11 2021
May 10 2021
@teemperor let me know if this test is OK, or if there's a better way to test this :)
Add GetExeModuleWhenMissingSymbolFile tesst.
Apr 30 2021
Apr 29 2021
Rely on unique_ptr's bool operator, instead of checking the underlying pointer.
Change buffer unique pointer from void to uint8_t, eliminating the need to call malloc/free.
Apr 28 2021
Apr 27 2021
Apr 20 2021
Apr 15 2021
Hey @jasonmolenda thanks for the input, and nice empirical experiment! Do you think simply adding a setting that sleeps by a constant amount would be enough to model this problem?
Updates all calls to ReadMemory to keep the current behavior.
Apr 14 2021
@jasonmolenda I've updated all the function calls to prefer the file cache (except the one you pointed out), but I'm a little worried about this, since I changed a lot of function calls. Maybe I could update the function signature to force_live_memory (and default it to false), but keep all the current calls having the same behavior (by negating whatever was passed previously as prefer_file_cache). What do you think?
Changed the approach from a target setting to updating Target::ReadMemory to prefer the file cache (if section is read-only)
This patch introduces a new setting on ProcessGDBRemote to allow artificially slowing down the communication betwenn lldb and the server. The new setting sleeps PacketDelayMultiplier nanoseconds per byte read or written in GDBRemoteCommunication.
Apr 13 2021
@jasonmolenda actually, most of them are passing prefer_file_cache = false, unfortunately. But they might be doing this because there's they weren't sure if the memory was writable, so this was the safer option. I want to change all the ones we deem safe to force_live_memory = false, which is why I ask which files you think this change would be safe.
Thanks for the input @jasonmolenda. FWIW I also think it's worth implementing this correctly.
Apr 12 2021
Mar 9 2021
I'm not sure this new functionality is really worth the new packet (or two), but if it solves a use case you care about, then I suppose that's fine.
We'll still need to be careful about using this functionality on the lldb side though. This fix will only help if there is proper synchronization between using this function and libedit initialization
Feb 7 2021
One alternative could be to just tack on some extra data to the existing vAttach family packets (vAttachWait;foo;interval:47;duration=74).
Feb 5 2021
As discussed in the vAttachWait patch (https://reviews.llvm.org/D93895), I've implemented a jAttachWait packet with supports two additional parameters (polling interval and polling duration) when attaching to a process by name and waiting for it to appear.
Feb 1 2021
Jan 22 2021
This is the second (and better) solution that addresses this issue. Previous discussions can be found here.
@labath sorry for the repeated messages. I believe this is ready to be merged, right?
@labath, you were absolutely correct! It was simply a matter of saving and restoring the terminal struct on the terminalHasColors function in the Process.inc file (I really should've tried that before). I'm currently recompiling and will re-run the tests locally, and will push the changes after that. I do worry this could potentially impact macOS though (I don't know if these low-level terminal functions work differently between differently OSes), so how do we ensure this doesn't break anything there?
Jan 21 2021
Jan 20 2021
Jan 14 2021
Addresses comments, includes tests.
Jan 12 2021
Jan 10 2021
Looks good, modulo the inline comment.
Jan 6 2021
Changes test to launch a process before and after we ask for the attach. Minor code fixes as well.
Back to implementation of vAttachWait
I don't think it's a good idea to stuff all of this into a single patch. Can we go back to the version which just implements the basic vAttachWait packet (we can bikeshed on what the default interval should be)? I believe new commands/options/packets should be done in separate patches...
Ok, that makes sense!
Jan 5 2021
I think I get your point. If we pass the extra options in the packet, the validation on older lldb-server versions will reject the message.
Here lies the problem that I mentioned above. I would like to avoid having to launch lldb-server with any arguments so that we continue to work with older lldb-servers.
So it might be nice to add support for vAttachOrWait, along with the query packet, in this patch if you have the time?
Question: why does lldb queries if vAttachOrWait is supported, but not vAttachWait? Does it make sense to keep this query? Or should I remove it?
@clayborg I've added support for the 'waitfor-interval' and 'waitfor-duration' flags. Yesterday I thought they existed in macOS, but now I'm not so sure, as I couldn't find them on "Options.td". They were added in 2009, so maybe they did exist but were dropped later. Or I just didn't look at the right place.
Adds support to 'vAttachOrWait', as well as the 'waitfor-interval' and 'waitfor-duration' flags.
Jan 4 2021
Jan 2 2021
Fix issues pointed out in comments left in previous patch, and clean the code a bit
Jan 1 2021
Hi @labath. Ok, I believe the test is passing now. Thank you for all the help today!
Re-include deleted files.
Hi @labath. I see! I changed it to lldbgdbserverutils.gdbremote_hex_encode_string. Looking at the logs, I found that the checksum I inserted was wrong, so I've corrected that as well (is there a way I can calculate the checksum on the test, instead of hard-coding it in the string?). Despite these changes, I still get the same error (ConnectionResetError: [Errno 104] Connection reset by peer on line 46).
Dec 29 2020
Fix formatting issues