Bug 1723638

Side but related topic.  While the existing search command is very powerful and covers A LOT of cases, it looks like search is fundamentally unreliable especially if you are not really careful to know how it works.  For example, you need to know the alignment ahead of time for any given search pattern or search fails.  In short, it does not look like 'search' really finds a pattern reliably in memory in all cases and it's easy to use it incorrectly.

In practice, I am not sure how much people know this or it is a problem.  But to me it seems like there's room for improvement beyond just speeding up search.

Here are a few examples:
crash> 
crash> rd -8 ffff88ee18eebde0 96
ffff88ee18eebde0:  30 21 19 81 ff ff ff 00 80 f7 00 f2 f4 88 ff ff   0!..............
ffff88ee18eebdf0:  a8 da 90 a4 7e 88 ff ff 25 fe ff ff 00 00 00 00   ....~...%.......
ffff88ee18eebe00:  00 d0 ff 2b 3c 7f 00 00 ff cf ff 2b 3c 7f 00 00   ...+<......+<...
ffff88ee18eebe10:  a8 ed 3a 59 01 ea ff ff 00 00 00 00 00 00 00 00   ..:Y............
ffff88ee18eebe20:  90 96 a9 3b 00 ea ff ff 60 f0 32 28 00 88 ff ff   ...;....`.2(....
ffff88ee18eebe30:  00 d0 ff 2b 00 00 00 00 00 d0 ff 2b 3c 7f 00 00   ...+.......+<...

Here I would expect it would find '0xffff' but it does not:
crash> search -s 0xffff88ee18eebde0 -e 0xffff88ee18eebe40 0xffff

You need to specify the length or a mask.  Technically, a more thorough output would show 0xe5 as well as 0xe4 address since both match (alignment issue though)
crash> search -s 0xffff88ee18eebde0 -e 0xffff88ee18eebe40 -h 0xffff
ffff88ee18eebde4: ffff 
ffff88ee18eebdee: ffff 
ffff88ee18eebdf6: ffff 
ffff88ee18eebdfa: ffff 
ffff88ee18eebe16: ffff 
ffff88ee18eebe26: ffff 
ffff88ee18eebe2e: ffff 

I'm more concerned about cases like this, where if the bytes are misaligned (and you don't know it ahead of time or don't want to assume alignment) search does not work at all:
crash> search -s 0xffff88ee18eebde0 -e 0xffff88ee18eebe40 -h 0x2b3c
crash> search -s 0xffff88ee18eebde0 -e 0xffff88ee18eebe40 -h 0x3c2b
crash> 

To find that you have to use masks and if you don't want to assume alignment, use multiple searches which will be very expensive.
crash> search -s 0xffff88ee18eebde0 -e 0xffff88ee18eebe40 0x0000003c2b000000 -m 0xffffff0000ffffff
ffff88ee18eebe00: 7f3c2bffd000 
ffff88ee18eebe08: 7f3c2bffcfff 
ffff88ee18eebe38: 7f3c2bffd000 

Not sure how important this is in practice since most of the time my guess is we do know alignment.  However I know I've seen pointers written misaligned, scribbling over one byte of memory.  I suppose those are fairly obvious though so maybe not relevant to search.

I'll see if I can get some other opinions on this - how well know limitations are and whether people think these are an issue or not, or if just speed is the issue.
The good news is many algorithms should also take care of this limitation, though I'm not sure how important it is to tackle and there's often many ways to improve performance.

I didn't get any time to look at this for 8.2.  Hope springs eternal, at least for 8.3, after which it may not.  ;-)