James Washer wrote:
I suspect crash is simply using a standard disassembler, but it's driving me nuts that I get output like: 0xc0000000000cbc18 <.do_sys_open+0xa8>: xori r29,r29,16384 rather than hex "immediates"... Is there anyway to alter this behavior? thanks - jim
Hi Jim, Crash uses the gdb disassembly code, although each architecture has a filtering routine that re-translates the <function-name+offset> at the beginning (sometimes gdb does it incorrectly), and also displays the offset value depending upon the hex/dec setting you've got in effect at the time. Other arches also add a <function-name+offset> at the end of a line when the gdb disassembly only displays "call 0xaddress". But to answer your question, with respect to intermediate values, the x86, x86_64, and I think the ia64, all show intermediates in hexadecimal. Kind of strange that the ppc64 does it differently. I do tinker with gdb's output-radix and output-format internal variables, but they don't affect disassembly output at all. Anyway, I don't know of any way to change gdb's behaviour although there very well may be an internal variable that controls it. The real answer can be found by tracking the combination of the gdb-6.1/opcodes/ppc-opcodes.c, gdb-6.1/opcodes/ppc-opc.c, gdb-6.1/gdb/disasm.c and gdb-6.1/printcmd.c code -- a PITA to follow -- but the real answer is in there somewhere. I do note that the address+offset output is hardwired to print decimal in print_address_symbolic() function in gdb-6.1/gdb/printcmd.c, but I haven't tracked down where the intermediates get printed. If that were determined, then it seems that it could be tinkered with based upon crash's hex/dec setting. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility