- User Since
- Feb 26 2020, 5:19 PM (13 w, 4 d)
Thu, May 28
Wed, May 27
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.
Sun, May 24
Maybe we can skip the unified requirements checking now, coz it has got many things to deal with.
Added back the local checking here.
Fri, May 22
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.
Sun, May 17
Removed local requirements checking. Added periods.
Thu, May 14
Wed, May 13
Sounds that the breakpoint-id completion needs to be improved in the future. Thanks for pointing this out!
Tue, May 12
Mon, May 11
Sat, May 9
Thank you for your advice Jonas.
Btw, I also modified the raw Breakpoint pointer to be a BreakpointSP.
Wed, May 6
- 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.