GNU/Weeb Mailing List <[email protected]>
 help / color / mirror / Atom feed
* [PATCH] scripts/decodecode: Make objdump always use operand-size suffix
@ 2022-03-01  4:11 Ammar Faizi
  2022-03-01  8:41 ` Borislav Petkov
  0 siblings, 1 reply; 4+ messages in thread
From: Ammar Faizi @ 2022-03-01  4:11 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: weidonghui, tools, linux-kernel, gwml, x86, Ammar Faizi,
	Andrew Morton, Andy Lutomirski, Dave Hansen, H. Peter Anvin,
	Ingo Molnar, Thomas Gleixner

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 <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
---
 scripts/decodecode | 2 ++
 1 file changed, 2 insertions(+)

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
 }

base-commit: 7e57714cd0ad2d5bb90e50b5096a0e671dec1ef3
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts/decodecode: Make objdump always use operand-size suffix
  2022-03-01  4:11 [PATCH] scripts/decodecode: Make objdump always use operand-size suffix Ammar Faizi
@ 2022-03-01  8:41 ` Borislav Petkov
  2022-03-01  9:16   ` Ammar Faizi
  0 siblings, 1 reply; 4+ messages in thread
From: Borislav Petkov @ 2022-03-01  8:41 UTC (permalink / raw)
  To: Ammar Faizi
  Cc: weidonghui, tools, linux-kernel, gwml, x86, Andrew Morton,
	Andy Lutomirski, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Thomas Gleixner

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts/decodecode: Make objdump always use operand-size suffix
  2022-03-01  8:41 ` Borislav Petkov
@ 2022-03-01  9:16   ` Ammar Faizi
  2022-03-01 10:44     ` Borislav Petkov
  0 siblings, 1 reply; 4+ messages in thread
From: Ammar Faizi @ 2022-03-01  9:16 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: weidonghui, tools, linux-kernel, gwml, x86, Andrew Morton,
	Andy Lutomirski, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Thomas Gleixner

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.

-- 
Ammar Faizi

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts/decodecode: Make objdump always use operand-size suffix
  2022-03-01  9:16   ` Ammar Faizi
@ 2022-03-01 10:44     ` Borislav Petkov
  0 siblings, 0 replies; 4+ messages in thread
From: Borislav Petkov @ 2022-03-01 10:44 UTC (permalink / raw)
  To: Ammar Faizi
  Cc: weidonghui, tools, linux-kernel, gwml, x86, Andrew Morton,
	Andy Lutomirski, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Thomas Gleixner

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-03-01 10:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-01  4:11 [PATCH] scripts/decodecode: Make objdump always use operand-size suffix Ammar Faizi
2022-03-01  8:41 ` Borislav Petkov
2022-03-01  9:16   ` Ammar Faizi
2022-03-01 10:44     ` Borislav Petkov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox