----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
