[Crash-utility] Is there a way to get hex immediates in ppc disassembly?

Dave Anderson anderson at redhat.com
Mon Jun 23 13:49:49 UTC 2008


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




More information about the Crash-utility mailing list