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.