[Crash-utility] RFC: Improving crash's search speed

[Dave Anderson]

----- Original Message -----
> On Wed, 2011-01-26 at 20:29 +0000, Dave Anderson wrote:
> 
> >
> > I've pretty much got -p working OK, and next I'll plug in the -KVM restrictors.
> 
> By the way, thanks for running with this.
> 
> 
> >
> > > Today I'm trying to find out why parse_line() is messing up when given
> > > more than one string in ""'s.
> >
> > Not sure I understand how you can do that, but don't let me interfere...
> 
> The syntax for the search command:
> search [-s start | -k | -u] [-e end | -l length] [-m mask] value ...
> 
> allows multiple values for simultaneous search. For example:
> 
> crash-5.1.1str> search -k 00007ffffd401e28 00007f29a0cbeb9f
> ffff88011e889f70: 7ffffd401e28
> ffff88011e889fd8: 7f29a0cbeb9f
> 
> I thought I'd use a similar syntax for strings (-c for "chars", looking
> for a better letter, maybe -S):
> 
> crash-5.1.1str> search -k -c "Memory value expected" "No such file or"
> 
> The current version of parse_line in tools.c has a problem with repeated
> strings, so that it delivers the following in the value[] array:
> 
> (gdb) p value[0]
> $1 = 0xb74a04 "Memory value expected"
> (gdb) p value[1]
> $2 = 0xb74a1b "\"No"
> (gdb) p value[2]
> $3 = 0xb74a1f "such"
> (gdb) p value[3]
> $4 = 0xb74a24 "file"
> (gdb) p value[4]
> $5 = 0xb74a29 "or\""
> 
> With the attached patch, it delivers:
> 
> (gdb) p value[0]
> $1 = 0xb77a24 "Memory value expected"
> (gdb) p value[1]
> $2 = 0xb77a3c "No such file or"
> 
> I don't think it messes anything else up...

I don't believe so either -- the patch makes good sense.  Thanks
for tracking that down.  Strange that it would only "break up" the
2nd, 4th, 6th, etc. string arguments.  I didn't bother trying to
understand why that happens...)  

Queued for the next release.

Thanks,
  Dave