----- Original Message -----
yes, I mean crash command line is lacking support of some advanced arithmetic,
like this pd command, it doesn't have to send it to gdb;
BTW, these days I am looking for an advanced scripting in crash, does crash
provide some builtin script language?
Nope. What you see is what you get.
Or have you looked this pykdump project, to embed a python interpreter sounds
like a good idea, since gdb has support python scripting as well,
http://sourceforge.net/projects/pykdump/
I'm aware of it, and know that it's useful to those that do use it. I don't
speak
python, and if I really need something that I can't get out of the command set
I find it easier to write something in C for the hidden "test" command, or
by a quick-and-dirty extension module.
Dave
Thanks,
On Wednesday, May 20, 2015 11:17 AM, Dave Anderson <anderson(a)redhat.com>
wrote:
----- Original Message -----
>
> Hi Dave,
> Does this sound like a bug, it need right shift of the subtraction result,
> crash-git> pd (678324157984276 >> 32)
> $10 = 157934
> crash-git> pd ((681670518181331-678324157984276) >> 32)
> p: gdb request failed: p ((681670518181331-678324157984276)
> crash-git>
>
> It might be lacking support of some advanced arithmetic, so what is a
> proper
> wayto do some arithmetic like this?
No, it is a crash bug. If you turn on the console mode, you can see the
string
that is passed on to gdb. Simple example:
crash> !tty
/dev/pts/8
crash> set console /dev/pts/8
debug console [2850]: /dev/pts/8
console: /dev/pts/8
crash> set debug 1
debug: 1
crash>
The simple shift case works, and you can see the string that gets passed
to gdb on the 2nd line of output, in the bracket after gdb_pass_through:
crash> pd (15 >> 1)
error() trace: 467e99 => 51c147 => 518ca6 => 46eaff
gdb_pass_through: [p (15 >> 1)]
p: per_cpu_symbol_search((15 >> 1)): NULL
$9 = 7
crash>
But by adding the internal set of parentheses, the string gets
clipped, and just "p ((15+1)" gets passed to gdb:
crash> pd ((15+1) >> 1)
error() trace: 467e99 => 51c147 => 518ca6 => 46eaff
p: per_cpu_symbol_search(((15+1)): NULL
gdb_pass_through: [p ((15+1)]
error() trace: 467e99 => 51c1e7 => 51a7d5 => 46eaff
p: gdb request failed: p ((15+1)
crash>
So it's either related to the crash command line redirection code,
or in the process_gdb_output() function. (Feel free to debug it
if you have the time...)
Thanks,
Dave