----- 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 <[email protected]> > 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 > > > -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
