[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whtFk2DoO8WhtmsbU9nGXUd8sKShV1Dk71krFLBjPUSeg@mail.gmail.com>
Date: Sat, 20 Jan 2024 09:00:14 -0800
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Thorsten Glaser <tg@...ian.org>, Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
rostedt@...dmis.org, linux-kernel@...r.kernel.org,
linux-toolchains@...r.kernel.org, jpoimboe@...hat.com,
alexei.starovoitov@...il.com, mhiramat@...nel.org
Subject: Re: [PATCH 1/2] x86: Remove dynamic NOP selection
On Sat, 20 Jan 2024 at 00:28, H. Peter Anvin <hpa@...or.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
Powered by blists - more mailing lists