Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: arbitrary text search in tarmac-browser #5

Open
pm215 opened this issue Jul 22, 2021 · 1 comment
Open

feature request: arbitrary text search in tarmac-browser #5

pm215 opened this issue Jul 22, 2021 · 1 comment

Comments

@pm215
Copy link

pm215 commented Jul 22, 2021

I'm playing around with tarmac-browser as an alternative to my traditional "just view the trace file with less" approach, and one feature I would really like is the ability to move around in the trace by arbitrary text search. In 'less' you can do this with:

  • /pattern to search forwards
  • ?pattern to search backwards
  • n to repeat the previous search

This lets you do ad-hoc things like "find the first VLDR in the trace", or "find the last point in the trace where some register had the value 0x8080". (Less critically, it also means I don't have to get used to a different interface for "go to this PC", because /3901bd80 would then work for that just as it does in less.)

@statham-arm
Copy link
Contributor

Well, /3901bd80 might work – or it might find you some other use of the same address, such as it being loaded as a function pointer shortly before the call, or included in a memcpy at some totally different time. (But then, perhaps you intended to find those too.)

But yes, I agree it would be useful not to have to step out of the tarmac-browser UI to do this. I expect I'd use it myself, e.g. for finding text-only events such as CPU exceptions.

I think this is the kind of feature somebody could write without needing a lot of knowledge of the existing code, because it wouldn't need much engagement with the Tarmac logic or the index-querying API. All you'd need to do would be to find the current file position (which is easy to find out as both a line number and a byte offset) and hand off to some completely separate new code that would do the search and return a new line number or byte position to jump the viewer to.

And we're already requiring C++14, so the standard C++ <regex> header ought to be available on all target platforms (including Windows).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants