This is an archive of the discontinued LLVM Phabricator instance.

[LLDB] Add color to output text when searching for symbols
Needs ReviewPublic

Authored by varunkumare99 on Oct 21 2022, 9:06 AM.

Details

Summary

added support for colored output for the commands

  1. image lookup -r -s <func-regex>
  2. image lookup -r -n <func-regex>

For option (1) lookupSymbolInModule(CommandObjectTarget.cpp) is called. We first match the regex against the symbol names. Then update the
name(Symbol Demangled name) with colored matches. So that the symbol when displayed down the line(in SymbolContext.DumpStopContext) is printed
with colored text. Once the symbols are displayed, we restore the original symbols names.(Symbol Demangled name)

For option (2) lookupfunctionInModule(CommandObjectTarget.cpp) is called. As the symbol names are accessed in Module.cpp we repeat the
above process in it.

Diff Detail

Event Timeline

varunkumare99 created this revision.Oct 21 2022, 9:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 21 2022, 9:06 AM
varunkumare99 requested review of this revision.Oct 21 2022, 9:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 21 2022, 9:06 AM
labath added a subscriber: labath.Oct 24 2022, 1:59 AM

This is definitely not a good way to implement this functionality. There's no telling who else might be accessing the symbols while their names are being changed.

The colouration should be implemented inside the dumping function, without modifying the state of the debugger. I realize that's not currently easy to do, but that's not a reason to do this. It's possible the dumping machinery needs to be refactored to support this kind of customized colouration.

I agree that this change names - print - restore names is going to cause problems. Pavel is right that this should happen in some dump function somewhere.

But, assuming what you've got works to an extent, you should add some testing first. That will allow you to refactor with less risk. You'll be able to reuse a lot of the tests later, so it's not wasted effort and it'll flush out some corner cases you haven't thought of.

For how to test this I would look to the other commands that have colour (frame was one I think) and anything interacting with the colour settings.
(if you want a cheeky way to find the tests, delete some of the colouring code and run the test suite - whatever fails is going to be interesting to you)

lldb/source/Commands/CommandObjectTarget.cpp
1514

Doesn't seem like you need to enumerate them, so this could be:

for (const auto &p : positions)
   if (pos >= ....)
       return true;
return false;

(https://en.cppreference.com/w/cpp/language/range-for)

Or std::find(..., <lambda>) != positions.end() but same thing really.

Basically prefer iterators unless i is needed for something other than indexing.

If you do need the index but don't want the hassle of handling it yourself, there is an llvm::enumerate in llvm/include/llvm/ADT/STLExtras.h which acts like Python's enumerate.

And if it helps to refactor in parent patches to make this change easier, go for it. Maybe you add generic colouring support to something, then the last patch hooks it up to the symbol lookup, something along those lines.

This is definitely not a good way to implement this functionality. There's no telling who else might be accessing the symbols while their names are being changed.

The colouration should be implemented inside the dumping function, without modifying the state of the debugger. I realize that's not currently easy to do, but that's not a reason to do this. It's possible the dumping machinery needs to be refactored to support this kind of customized colouration.

thank you for the feedback. I will try adding colouration inside a dumping function.

varunkumare99 added a comment.EditedOct 25 2022, 7:40 AM

I agree that this change names - print - restore names is going to cause problems. Pavel is right that this should happen in some dump function somewhere.

But, assuming what you've got works to an extent, you should add some testing first. That will allow you to refactor with less risk. You'll be able to reuse a lot of the tests later, so it's not wasted effort and it'll flush out some corner cases you haven't thought of.

Thanks. I will start out with adding some testing first. Then look into adding colouration in dump functions.