linux-kernel - Re: [GIT PULL] objtool fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whYPrtGt6Qk6tregpQ8Xx7BiAh00STY7ne=Zm0NDHg6nQ@mail.gmail.com>
Date: Thu, 3 Apr 2025 08:58:35 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, linux-kernel@...r.kernel.org, 
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, Thomas Gleixner <tglx@...utronix.de>, 
	Borislav Petkov <bp@...en8.de>, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] objtool fixes

On Thu, 3 Apr 2025 at 07:53, Ingo Molnar <mingo@...nel.org> wrote:
>
> BTW., I do look at generated code, and I know others do too, but at the
> .o most of the time, not at the .s code, via two ways:
>
>       1) objdump --disassemble-all .
>
>       2) perf top's live kernel function annotation and disassembler
>          feature that uses /dev/mem.

Sure, I do both of those too.

However, you are quite wrong:

> Such output is more readable to me:

it's readable for some cases.

But in other cases, it loses a *lot* of information that is in the
generated assembler.

For example, gcc will helpfully annotate the asm output with the names
of the pseudos it uses, so you see things like this:

        movq    %rbx, %rax      # hashlen, __ret

where you see what the names of the variables are (and then for
pseudos that are just internal. you see things like "_31", which is
admittedly not helpful).

And yes, it's not exactly "legible", but it's the kind of thing that
does help when you look at code and don't have to follow by hand what
'%rbx' actually is.

(This is one reason I tend to prefer looking at gcc output over clang
- gcc adds more information like this, and admittedly I'm probably
*much* too used to all the oddities that gcc sometimes does)

So no - objdump and perf is not replacements for just looking at the
compiler output. They are *also* good sources, of course, but objdump
output in particular is just *horrendous*.

objdump still can't even do relocations right, for chrissake, so it
outputs usually just line noise. Any call to another object file will
be just noise:

0000000000000000 <vfs_pressure_ratio>:
       0:       call   5 <vfs_pressure_ratio+0x5>

that's the "call __fentry__" because objdump output is *so* bad.

It's not fit for humans.

I do still look at it in very particular circumstances, though.

           Linus