[Crash-utility] RFC: string search for crash

[Dave Anderson]

----- Original Message -----
> Here is a patch to add string search to crash-5.1.1.
> 
> It requires the my previous patch for the parse_line routine.
> 
> It searches for the specified strings, and for half or more of the
> string appearing at the start and end of search blocks (usually pages)
> in case the string spans a page boundary.
> 
> It is currently invoked with the -c option to search, as in:
> 
> crash-5.1.1str> search -k -e 0xffffc90000000000 -c "getty[3895]"
> ffff880123b54810: :46 getty[3895]: /dev/ttyS1: No such file or dir
> 
> or
> 
> crash-5.1.1str> search -k -c -e 0xffffc90000000000 "getty[3895]"
> ffff880123b54810: :46 getty[3895]: /dev/ttyS1: No such file or dir
> 
> It reports the found string in 48 chars of context (except
> at the end of pages), and it reports aligned addresses, so the found
> string doesn't always appear at the beginning of the context (as in the
> example above).
> 
> It could optionally use strncasecmp to do case-insensitive searches.
> 
> I simplified it :-) by combining the main and tail searches into one
> loop and added a 10-15% performance degradation somewhere.
> 
> Here it searches the dump for bugs and danger :-)
> 
> crash-5.1.1str> search -k -c -e 0xffffc90000000000 "bugs" "danger"
> ffff8801254c0ff8: ug:Debug
> ffff880125cd4ff8: ebian/bu
> ffff880125ec8870: efb: danger danger! Oopsen imminent!..<6>Mode (%
> ffff880125ec8878: ger danger! Oopsen imminent!..<6>Mode (%dx%d) la
> ffff880125eee518: ofb: danger danger! Oopsen imminent!..<3>neofb:
> ffff880125eee520: ger danger! Oopsen imminent!..<3>neofb: neo2200
> ffff880125f72000: ger_event.......................................
> ffff880125fc3560: ice bugs (default = 0, 128kB max transfer = 0x1,
> 
> The first two hits come because half or more of "bugs" occurred at the
> end of a page. The next to the last hit is found because the last
> half of "danger" appears at the beginning of a page.
> 
> Bob Montgomery

Hi Bob,

A couple things...

First, this is a really nifty feature...

Second, I appreciate that you created a new string_search() function
instead of attempting to merge it into the existing search() function.
I'm doing the same thing for implementing the "-p" functionality because
physical addresses may require 64-bit start/end addresses on 32-bit machines,
However, I did have to change cmd_search() to use ulonglong's for start
and end.  Then trying to shoe-horn physical memory searching into
the existing virtual-memory-presuming search() command was way too ugly
to consider. 

Third, given that you're searching for specific string, why not show
the actual byte-aligned address as the starting point, and then just
display the string contents until the next non-ASCII character, or some
other delimiter like a 48 byte limit or whatever?

I understand that the page-crossing issue is a PITA, but with respect
to a user searching memory for strings, the page-crossing issue is
seemingly irrelevant.  In other words, why this:

> ffff880125f72000: ger_event.......................................

instead of displaying something like this:

  ffff880125f71ffd: danger_event

So I guess I'm just wondering why the "dan" at the end of the page 
cannot be displayed?  It just doesn't seem user-friendly to force
the user to understand the half-of-the-string-at-a-page-boundary
business.  Since you do recognize that string exists and crosses
a page boundary, shouldn't you be able to display the first part? 

Lastly, I'm still planning to add the remaining "search" command
updates for the -KVM flags and the "missing" x86_64 segment bug,
and so I may need you to re-work this patch to fit into an updated
version of search().  I've been delayed getting crash-5.1.2 out
the door because of all of the recent patch postings, and it may
be worth waiting to get this piece in until 5.1.3 -- is that OK
with you?

Thanks,
  Dave