[Bug] Changes made in commit #81ee52d mean that register order is no longer maintained in context #986
Description
GEF+GDB version
master branch of GEFOperating System
Ubuntu, Debian
Describe the issue you encountered
Previously list comprehensions were used for filtering the registers requested in DetailRegistersCommand(GenericCommand) (around line 6733). This got changed in commit 81ee52d to use set instead.
Because set is unordered, changing the way the register filtering is done results in the registers printing in an unexpected order.
Previously you'd get $rax, $rbx, $rcx in order:
$rax : 0x0
$rbx : 0x0
$rcx : 0x0
$rdx : 0x0
$rsp : 0x00007fffffffde70 → 0x0000000000000001
$rbp : 0x0
$rsi : 0x0
$rdi : 0x0
$rip : 0x00007ffff7fe32b0 → <_start+0> mov rdi, rsp
$r8 : 0x0
$r9 : 0x0
$r10 : 0x0
$r11 : 0x0
$r12 : 0x0
$r13 : 0x0
$r14 : 0x0
$r15 : 0x0
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000
Now you get:
$rdx : 0x0
$rsi : 0x0
$rdi : 0x0
$rbp : 0x0
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$r8 : 0x0
$rbx : 0x0
$r12 : 0x0
$rcx : 0x0
$r9 : 0x0
$rsp : 0x00007fffffffe590 → 0x0000000000000001
$rip : 0x00007ffff7fe32b0 → <_start+0> mov rdi, rsp
$r11 : 0x0
$r13 : 0x0
$r15 : 0x0
$r10 : 0x0
$r14 : 0x0
$rax : 0x0
$es: 0x00 $ds: 0x00 $fs: 0x00 $cs: 0x33 $ss: 0x2b $gs: 0x00
It's possible that the new code will always return the registers in the same order, but I don't believe that there's any guarantee of this due to set being specifically unordered and the order they are returned in does not feel logical to me whilst looking for the contents of a specific register (i.e. I expect $rax to be the first result, I don't expect to have to hunt for it). As such, I believe that this should be reverted so that the behaviour returns results in an expected and consistent order.
Do you read the docs and look at previously closed issues/PRs for similar cases?
Yes
Architecture impacted
- X86
- X64
- ARM
- ARM64
- MIPS
- MIPS64
- PPC
- PPC64
- RISCV
Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.
Run GDB, hit a breakpoint or use starti.
Older version show registers in expected order, new version doesn't.
Minimalist test case
N/A - Any binary should do it
Additional context?
N/A