Hi everyone,
I’m planning to include some new commands in lldb. Initially I thought of creating aliases of gdb commands which are not available in lldb (like "break args" instead of "breakpoint set -flags args"). But then I realized that lldb follows a noun verb format rather than gdb and it’s not a good idea (to create some sort of gdb clone in lldb).
Now I want to ask the community what kind of features do they think are missing in lldb right now which I can try adding in the code base of lldb so that I can create some new commands.
Also I’m a beginner and still trying to understand the source code. I’ve added few commands related to breakpoints, like "breakpoint setbacktrace args", which prints the backtrace whenever a breakpoint is hit. So it will be a great idea if someone can suggest me the new commands in hierarchical order i.e., from integrating easier commands to complex ones.
As for whole commands, no idea. If it were me I’d try porting over some useful gdb scripts and see what went wrong and survey my colleagues if possible.
But perhaps adding a whole command is a bit much to start out with (not that it’s that complicated, but there’s a lot of setup code which is hardly exciting).
I am reminded of Colorize output when searching for symbols in `lldb` · Issue #57372 · llvm/llvm-project · GitHub. Which is quite self contained and even has had one attempt at it. So you’ve got some test cases already. You could ping that person in a comment to see if they are still working on it, but I doubt it given that time that has passed.
It’s something everyone would appreciate and isn’t so big you’ll have to fight to add it.
1 Like
First off, I think a command like breakpoint setbacktrace args is too fine-grained for the lldb basic command set, after all, it’s really just the same as:
breakpoint command add -O bt
If we keep adding shims like this to the main command set it’s going to rapidly grow unwieldy. We sometimes add convenience aliases for common operations, though in this case, I don’t think the operation is common enough to warrant this. That’s not said as discouragement, but rather to give some context for thinking about what kind of commands we want to add.
One section of lldb that is lacking is the ability to react to the various events in the course of a debug session. We have an affordance for the user to react to stops in the target (target stop-hook) but not things like “target created”, “process launched”, “process exited” and so forth. The way the stop-hooks callbacks get registered could be pretty easily extended to other classes of “interesting lifecycle events”. That would also be a good excuse to dig into lldb to see how all these lifecycle events get triggered. But this is also moderately big project, and getting a nice general CLI interface will take some thinking. So it’s on the “complex” side.
Jim
On Sep 15, 2023, at 3:25 AM, Taalhaataahir0102 via LLVM Discussion Forums notifications@llvm.discoursemail.com wrote:
taalhaataahir0102
September 15Also I’m a beginner and still trying to understand the source code. I’ve added few commands related to breakpoints, like
"breakpoint setbacktrace args", which prints the backtrace whenever a breakpoint is hit. So please suggest me commands in hierarchical order i.e., from integrating easiest commands to complex ones.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
1 Like
Hi David. Just letting you know that I’m working on this along with one of my colleague. We’ve completely understood how colorization is working in the case of frame info and now we’re working on adding the colorization in the image lookup output as well. Hopefully we’ll be done by this week and will make a PR.
1 Like
Hi David. We saw the Phabricator review for the colorization task. The previous approach done which still remains in review is following:
changing the symbol names (making the searched part colorized) -> printing them -> restoring the symbol names back in their original form.
The reviewers guided that instead of changing the symbol table, this colorization should be done in the dump function itself.
The dump function used for the image lookup command is defined here:
Source/Core/Address.cpp
LLDB: Address.cpp Source File)
This is a general function which is used in other parts of lldb as well apart from dumping the image lookup output. Hence changing it might not be a good option and it also looks pretty much impossible. We were planning to write a new dump function (or overload the existing function) specific for image lookup. It will be similar to the original dump function. Only difference will be that we’ll pass the string or the indexes which needs to be colorized as an argument and will colorize that string in the output stream. So is it a good idea to overload the dump function for image lookup case?
First time looking at that function but I agree, it’s a monster. I would do what you suggested and write a new function to do this and get to the stage where you can test the feature thoroughly.
If then it turns out that we can integrate the changes into the old function, you can do so much more safely knowing the testing all works.
1 Like
Hi David,
We are almost done with the colorization by overloading the existing dump function (only few conor cases are left). However we were still confused regarding this one issue:
This is my regex symbol search for “m”:
Here the names are printed using this dump function LLDB: CommandObjectTarget.cpp Source File
To print the summary, the above dump function passes the symbol information to another dump function which is here LLDB: CommandObjectTarget.cpp Source File and this further uses the following dump function LLDB: Address.cpp Source File
For printing the symbol names in summary which have location information as well (as shown in the image red box), another dump function is used. Similarly, when we use verbose flag with the image lookup command e.g., in the above case:
image lookup -verbose -r -s m
Another dump function is used to print additional information LLDB: Symbol.cpp Source File
There might be some other cases left as well. So in total almost 5-6 dump functions needs to be overloaded in order to colorize the output completely (i.e., name, summary, summary using verbose etc.). This is going to increase the code size a lot as the overloaded dump functions are almost similar to the previous ones. The only difference is that we are now passing the string which needs to be colorized and colorizing it where the symbol is being printed in these new dump functions. Changing the existing dump functions is also dangerous as they are used in many other parts of the code base apart from the image lookup command. So what are your thoughts on this? Should we continue this approach of making new dump functions for image lookup symbol search command?
My approach here would be to continue making new copies of the Dump functions that are functional but not efficient or pretty. Then factor out the common parts once all my test cases are passing.
Once you have your 5/6 new functions you can find a common subset from that. If you do that before doing that, you’re likely to forget a corner case.
I would come up with a list of features that the sum of all those functions has, and see if you can make a smaller set that does it all. Some ways to do that might be a default argument for the matched string, that is "" in all cases but when a regex has been used. Or a modular approach where there is a print_symbol_name that all the Dump functions use. Perhaps you pass the name printer to the function, there’s many ways to do it.
Really depends on what that overall feature set is. If you want, you could post a draft pull request with all the new Dump functions and I’ll try to help spot some ways to do this.
Also, you should be protected by the test suite when doing this sort of refactoring. If you’re not 100% sure of that (we don’t have 100% coverage), try making an obvious mistake in one of the existing Dump functions. If no tests fail then we need more test coverage, if something fails, you’re ok to carry on making changes knowing it’ll catch your mistake.
1 Like
Hi David, we’ve initiated a PR with the required draft:
1 Like