Received-SPF: pass (google.com: domain of linux-kernel+bounces-31847-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20210312113253.305040674@infradead.org> <20210312115749.065275711@infradead.org>
 <Pine.BSM.4.64L.2401200654480.19429@herc.mirbsd.org> <CE53F232-3D2D-4910-94B4-A4304F5990C7@zytor.com>
In-Reply-To: <CE53F232-3D2D-4910-94B4-A4304F5990C7@zytor.com>
From: Linus Torvalds <torvalds@linuxfoundation.org>
Date: Sat, 20 Jan 2024 09:00:14 -0800
Message-ID: <CAHk-=whtFk2DoO8WhtmsbU9nGXUd8sKShV1Dk71krFLBjPUSeg@mail.gmail.com>
Subject: Re: [PATCH 1/2] x86: Remove dynamic NOP selection
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thorsten Glaser <tg@debian.org>, Peter Zijlstra <peterz@infradead.org>, x86@kernel.org, 
	rostedt@goodmis.org, linux-kernel@vger.kernel.org, 
	linux-toolchains@vger.kernel.org, jpoimboe@redhat.com, 
	alexei.starovoitov@gmail.com, mhiramat@kernel.org
Content-Type: text/plain; charset="UTF-8"

On Sat, 20 Jan 2024 at 00:28, H. Peter Anvin <hpa@zytor.com> wrote:
>
> %eiz was something that binutils used to put in when disassembling certain redundant encodings with SIB at some point.

Yeah, it's purely (bad) syntactic sugar for "no register". Somebody
decided that the fact that so many RISC architectures have a "zero
register" means that they should make x86 look like it has a "zero
register" too.

I assume it regularized some very silly decoding issue, but it was horrible.

It's not the worst thing I've ever seen - in objdump output, and it's
easy to just remove with a sed script or a simple search-and-replace
in the editor.  Unlike some of the other "design" choices of objdump.

On that note, does anybody have a better disassembler than objdump? Or
even a script around it to make it more useful? I do use "objdump
--disassemble" a fair amount, and I hate how bad it is.

My pet peeve is the crazy relocation handling (or lack there-of). IOW,
if I do something like

    objdump --disassemble \
        --no-show-raw-insn
        --no-addresses \
        kernel/exit.o

I get output like this:

        call   <delayed_put_task_struct+0x1a>

whis is garbage: it's not calling delayed_put_task_struct+0x1a at all,
that's just "the offset bytes are all zero because the data is in the
relocation".

And if I add "-r" to get relocation info, I get

        call   <delayed_put_task_struct+0x1a>
                        R_X86_64_PLT32  rethook_flush_task-0x4

which shows the raw relocation data, but with truly mind-bogglingly
horrendous syntax.

Is there some sane tool that just does the sane thing and shows this as

        call   rethook_flush_task

which is what the thing actually means?

And no, the llvm-objdump thing isn't any better. It isn't compatible
with the GNU binutils objdump, but it does the same insanely bad
decoding.

            Linus