Upon running info registers in gdb, we get an output similar to the following:
rax 0x1c 28 rbx 0x0 0 rcx 0x400a60 4196960 rdx 0x7fffffffde88 140737488346760 rsi 0x1 1 rdi 0x400932 4196658 rbp 0x0 0x0 rsp 0x7fffffffde68 0x7fffffffde68 r8 0x400ad0 4197072 r9 0x7ffff7dea560 140737351951712 r10 0x7fffffffdc30 140737488346160 r11 0x7ffff7732dd0 140737344908752 r12 0x4007f0 4196336 r13 0x7fffffffde80 140737488346752 r14 0x0 0 r15 0x0 0 rip 0x7ffff7732dd0 0x7ffff7732dd0 eflags 0x202 [ IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
While I do understand the for rax, rcx etc, GDB is converting the value to decimal for the second column, this doesn't seem consistent. Some registers, namely rsp and rip show the same value in hex, even in the second column. eflags on the other hand shows the flags in the second column.
What is the reason that gdb does this? If it is going to show the same info (in case of rsp and rip), isn't it redundant? Also, how does this generalize on other architectures? (The above output is for x86-64).
Source. I re-asked this question since I thought I would find more specific answer in reverse engineering point of view.