- User Since
- Feb 26 2020, 5:19 PM (58 w, 6 d)
Aug 27 2020
- Rebased the patch with the latest master branch and refactored FormattersContainer::AutoComplete with the latest interface.
Aug 23 2020
- Refactored the test with spawnSubprocess and modified main.cpp.
Aug 21 2020
- Rebased the patch with the latest master branch from Github;
- In test, uses the pid got from psutil.pids() instead of the one generated by creating a new process in case the pickle error.
Aug 19 2020
- Now the server uses std::sort to sort the match result before writing into the response packet;
- Refactored the server-side test to run within the build directory.
Aug 15 2020
- Added an 'M' at the beginning of the response packet, updated related doc and tests.
Aug 14 2020
- Removed the unnecessary print line in GDBRemoteCommunicationServerPlatform.cpp;
- Updated the packet doc;
- Refactored the for-loop at line 359-364 in GDBRemoteCommunicationServerPlatform.cpp;
- Refactored the server-side test with str.encode().hex().
Aug 13 2020
- Updated the packet doc.
- Renamed packet related into "qPathComplete";
- Refactored response form into comma-separated;
- Moved the functions from GDBRemoteCommunicationServerCommon to GDBRemoteCommunicationServerPlatform;
- Refactored the server-side test into lldb-platform dedicated, combined test cases into just one;
- Now MockGDBServerResponder.qPathComplete responses with just an empty string.
Aug 11 2020
Aug 10 2020
- Extended the server test into 3 separated cases:
- disk file with 1 match and 2 matches;
- disk dir on non-windows platform (for '/');
- disk dir on windows (for '\').
- Renamed all "vFile:autocomplete" related into "qDiskAutocomplete";
- Refactored match response from "[cstr],[cstr]..." into "[length]:[str bytes][length]:[str bytes]...";
- Updated docs/lldb-platform-packets.txt;
- Use 85 as the server's response error code.
- Added a server test.
Aug 9 2020
- Corrected summary;
- Added a test case for client which provides mock response for autocomplete request and test completion on command line;
- Modified the argument order of the autocomplete request packet replacing vFile:autocomplete:<partial_path>,<only_dir> with vFile:autocomplete:<only_dir>,<partial_path>, so commas won't break partial path resolving.
Aug 6 2020
- Added a comment in thread_plan_script.py.
- Added a comment to describe that 11 indent value.
Aug 5 2020
Jul 24 2020
- Made the comment for EmptyStruct a Doxygen comment;
- Refactored m_formatter_kind_mask check with a macro CHECK_FORMATTER_KIND_MASK.
Jul 22 2020
- Use static_cast<lldb::LanguageType>(bit) instead of C-style cast.
Jul 20 2020
- Refactored the whole patch to provide two common completions: pid and process name.
- Allow processes with empty names appear in the completion list.
- Use do nothing instead of not work now.
Jul 19 2020
- Bound the completion to the arguments of the type 'eArgTypeName', so that options like type filter add -w can be completed.
- Applied completion to type category define.
Jul 18 2020
- Renamed completion function name from ThreadIndex to ThreadIndexes.
- Renamed completion function name from FrameIndex to FrameIndexes.
- Removed the argument cursor check in these commands: thread conitnue/exceptioin/info.
Jul 17 2020
- Set daemon to True on creating process, so that it will be killed with the test case ending (which was set to False by mistake).
Jul 8 2020
The test case failed due to a bug in dotest.py (the test runner).
Jul 7 2020
- replaced request.GetCursorIndex() != 0 with request.GetCursorIndex();
- renamed the loop variable at line 1005.
- clang-formatted related files;
- refactored line 2100 with StringRef;
- replaced files_pec.hasValue() to file_spec, file_spec.getValue() to *file_spec;
- removed an useless comment;
- added a new line at the end of breakpoints.json.
- refactored for-loop into while-loop;
- added a new line at the end of thread_plan_script.py.
Jul 6 2020
- added @skipIfRemote to the test case;
- added the comment explaining the process creation.
- added a test case for process load;
- replaced assertTrue(err.Success()...) with assertSuccess(err).
Jul 3 2020
- modified for loop;
- replaced pass with time.sleep(1) so that the test process won't take up CPU.
- replaced std::string with const std::string& in for loop;
- refactored the success segment with llvm::Optional<FileSpec> file_spec;
- added invalidation check in test.
Jun 9 2020
- For the necessity it's because lldb does filter out its own pid and the pid of the process it already attached to, so I create a process here to provide an available pid which is known to us and able to be found by the completion implementation.
- For the child process termination problem, with the process flag value daemon set to True, this child process should be terminated automatically if this test process is killed due to any exception.
Jun 5 2020
Wrap pid completion as a common completion.
Jun 4 2020
Removed one redundant newline in TestCompletion.py.
- modified newlines;
- using range-based for-loop now;
- modified the test case.
Jun 3 2020
Added arg index check.
May 28 2020
May 27 2020
That does make sense. I will split it into eArgTypeProcessPlugin and eArgTypeDisassemblePlugin along with the corresponding completion function names at the time I implement the disassemble related completion function.
May 24 2020
Maybe we can skip the unified requirements checking now, coz it has got many things to deal with.
Added back the local checking here.
May 22 2020
Thanks very much Jonas for pointing out my carelessness! And with your RAII idea, I think we can use the smart pointer to simulate the defer thing.
- Removed PID completion from this patch;
- Removed the first empty lines for cases;
- Modified the title and the summary.
May 17 2020
Removed local requirements checking. Added periods.
May 14 2020
May 13 2020
Sounds that the breakpoint-id completion needs to be improved in the future. Thanks for pointing this out!
May 12 2020
May 11 2020
May 9 2020
Thank you for your advice Jonas.
Btw, I also modified the raw Breakpoint pointer to be a BreakpointSP.
May 6 2020
- shortened lines in TestCompletion.py and CommandCompletions.cpp
- set eRegisterCompletion to (1u << 9) while eCustomCompletion to (1u << 10)
Mar 6 2020
Added a test case where test "process signal" without a running process.
Mar 4 2020
Added comments about the new version test for command frame variable.
Modified the test for frame variable so that it will not execute frame variable before completion test.
Added m_exe_ctx.Clear() at the end of CommandObject::HandleCompletion to ensure that nothing will be stored in m_exe_ctx between running commands.
Thanks labath, for noting me about my missing test and Cleanup()!
For the test, my idea is to modify the original test for frame variable to make it not run frame variable before completion.
For the Cleanup(), I've checked the related code. It seems that Cleanup() is used to clear m_exe_ctx ( by calling its member function Clear() ) and release m_api_locker. From the comment at the beginning of CheckRequirements(), it says "Every command should call CommandObject::Cleanup() after it has completed." and we can find that Cleanup() appears only at the end of Execute(). But from CommandInterpreter::GetExecutionContext, ExecutionContextRef::Lock and ExecutionContext::ExecutionContext(const ExecutionContextRef*, bool) we can know that, this process is just assignments on smart pointers. So I think using m_exe_ctx.Clear() here might be better.
Mar 3 2020
Removed individual execution context updating.
Mar 2 2020
removed unnecessary assignment in test
Update the current execution context, then get signals from the current process.
Thanks for pointing out my misunderstanding on the Unix signals, and fetching the list of valid signals from backend is always a better way indeed.
However, getting the current process from the current context m_exe_ctx which is got from m_interpreter will cause an issue that the completion won't be triggered before executing some process commands.
This is similar to frame variable cause these two commands both work on the base of the current context from m_interpreter.
In order to process completion successfully whenever we've got a valid process, I will update the current execution context both in m_interpreter and the current command object.
But what I am worried about is whether a new issue would be caused due to updating the current execution context.