| Message ID | 20220301041119.55085-1-ammarfaizi2@gnuweeb.org (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | scripts/decodecode: Make objdump always use operand-size suffix | expand |
On Tue, Mar 01, 2022 at 11:11:19AM +0700, Ammar Faizi wrote:
> For better reading, always use operand-size suffix for the generated
What does "better reading" mean here exactly?
See, there's a reason why -M suffix is not default in objdump. And in
my experience, I've never looked at objdump output and thought, "hm, so
the operand size insn mnemonic suffix is missing here". And if at all,
one usually wants to know the operand size of a single instruction - not
the whole bunch - and for that we tend to look at the vendor manuals
directly...
So I don't think this brings any improvement to the output but hey, I
could be missing a reason.
On 3/1/22 3:41 PM, Borislav Petkov wrote: > On Tue, Mar 01, 2022 at 11:11:19AM +0700, Ammar Faizi wrote: >> For better reading, always use operand-size suffix for the generated > > What does "better reading" mean here exactly? > > See, there's a reason why -M suffix is not default in objdump. And in > my experience, I've never looked at objdump output and thought, "hm, so > the operand size insn mnemonic suffix is missing here". And if at all, > one usually wants to know the operand size of a single instruction - not > the whole bunch - and for that we tend to look at the vendor manuals > directly... > > So I don't think this brings any improvement to the output but hey, I > could be missing a reason. > I am aware that for particular cases, we can deduce the operand-size from its operand. So using operand-size is not always mandatory. I would say always using operand-size is our habit in writing Assembly code. Especially for the Linux kernel. Looking at entry_64.S, entry_32.S and many Assembly files here, we always use the operand-size. It also helps to determine the size quickly. It gives us extra information about the operand size when sometimes it can be vague. For me (and probably other people who always take care of the operand-size), it is a convenience to have them in the objdump as well :) I don't think it's that urgent to have, but having it should not bother people who don't care with the operand-size suffix anyway.
On Tue, Mar 01, 2022 at 04:16:47PM +0700, Ammar Faizi wrote: > I would say always using operand-size is our habit in writing Assembly code. "our" is who? > Especially for the Linux kernel. Looking at entry_64.S, entry_32.S and many > Assembly files here, we always use the operand-size. It also helps to determine > the size quickly. When do you ever need to determine the operand size quickly? > It gives us extra information about the operand size when > sometimes it can be vague. So I'm looking at output of objdump -d arch/x86/entry/entry_64.o and it does by default add suffixes when it is not perfectly clear what the operand size is, for example: 6a 2b pushq $0x2b vs 41 51 push %r9 so I think the default of not explicitly adding suffixes when it is clear what size it is, is the most optimal one. > I don't think it's that urgent to have, but having it should not bother people > who don't care with the operand-size suffix anyway. So I'd prefer if this were a command line option which turns this on only for whoever absolutely needs it. Thx.
diff --git a/scripts/decodecode b/scripts/decodecode index c711a196511c..ab400891610f 100755 --- a/scripts/decodecode +++ b/scripts/decodecode @@ -98,6 +98,8 @@ disas() { fi fi + OBJDUMPFLAGS="$OBJDUMPFLAGS -M suffix" + ${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $t.o | \ grep -v "/tmp\|Disassembly\|\.text\|^$" > $t.dis 2>&1 }
For better reading, always use operand-size suffix for the generated AT&T syntax Assembly code. $ echo "Code: 50 e0 49 8b 4e 08 48 8b 51 50 48 85 d2 75 03 48 8b 11 48 c7 c7 02 " \ "47 40 a1 48 89 c6 48 c7 c1 b6 38 3f a1 31 c0 e8 25 72 d5 df <0f> 0b 41 bc 01" \ "00 00 00 e9 da fb ff ff 48 8b 2b 48 8b 7d 08 e8 fc" | scripts/decodecode Before this patch: ------------------ All code ======== 0: 50 push %rax 1: e0 49 loopne 0x4c 3: 8b 4e 08 mov 0x8(%rsi),%ecx 6: 48 8b 51 50 mov 0x50(%rcx),%rdx a: 48 85 d2 test %rdx,%rdx d: 75 03 jne 0x12 f: 48 8b 11 mov (%rcx),%rdx 12: 48 c7 c7 02 47 40 a1 mov $0xffffffffa1404702,%rdi 19: 48 89 c6 mov %rax,%rsi 1c: 48 c7 c1 b6 38 3f a1 mov $0xffffffffa13f38b6,%rcx 23: 31 c0 xor %eax,%eax 25: e8 25 72 d5 df call 0xffffffffdfd5724f 2a:* 0f 0b ud2 <-- trapping instruction 2c: 41 bc 01 00 00 00 mov $0x1,%r12d 32: e9 da fb ff ff jmp 0xfffffffffffffc11 37: 48 8b 2b mov (%rbx),%rbp 3a: 48 8b 7d 08 mov 0x8(%rbp),%rdi 3e: e8 .byte 0xe8 3f: fc cld Code starting with the faulting instruction =========================================== 0: 0f 0b ud2 2: 41 bc 01 00 00 00 mov $0x1,%r12d 8: e9 da fb ff ff jmp 0xfffffffffffffbe7 d: 48 8b 2b mov (%rbx),%rbp 10: 48 8b 7d 08 mov 0x8(%rbp),%rdi 14: e8 .byte 0xe8 15: fc cld After this patch: ------------------ All code ======== 0: 50 pushq %rax 1: e0 49 loopneq 0x4c 3: 8b 4e 08 movl 0x8(%rsi),%ecx 6: 48 8b 51 50 movq 0x50(%rcx),%rdx a: 48 85 d2 testq %rdx,%rdx d: 75 03 jne 0x12 f: 48 8b 11 movq (%rcx),%rdx 12: 48 c7 c7 02 47 40 a1 movq $0xffffffffa1404702,%rdi 19: 48 89 c6 movq %rax,%rsi 1c: 48 c7 c1 b6 38 3f a1 movq $0xffffffffa13f38b6,%rcx 23: 31 c0 xorl %eax,%eax 25: e8 25 72 d5 df callq 0xffffffffdfd5724f 2a:* 0f 0b ud2 <-- trapping instruction 2c: 41 bc 01 00 00 00 movl $0x1,%r12d 32: e9 da fb ff ff jmpq 0xfffffffffffffc11 37: 48 8b 2b movq (%rbx),%rbp 3a: 48 8b 7d 08 movq 0x8(%rbp),%rdi 3e: e8 .byte 0xe8 3f: fc cld Code starting with the faulting instruction =========================================== 0: 0f 0b ud2 2: 41 bc 01 00 00 00 movl $0x1,%r12d 8: e9 da fb ff ff jmpq 0xfffffffffffffbe7 d: 48 8b 2b movq (%rbx),%rbp 10: 48 8b 7d 08 movq 0x8(%rbp),%rdi 14: e8 .byte 0xe8 15: fc cld Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> --- scripts/decodecode | 2 ++ 1 file changed, 2 insertions(+) base-commit: 7e57714cd0ad2d5bb90e50b5096a0e671dec1ef3