linux-kernel - Re: odd objtool 'unreachable instruction' warning

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: <es4awalt6i63cy5kkrbz7f22cxpt4zbmq6zsbol3yafek2375e@6b6stnc6k6h2>
Date: Tue, 28 Oct 2025 18:50:21 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Alexandre Chartre <alexandre.chartre@...cle.com>
Subject: Re: odd objtool 'unreachable instruction' warning

On Tue, Oct 28, 2025 at 05:59:01PM -0700, Linus Torvalds wrote:
> On Tue, 28 Oct 2025 at 17:21, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> >
> > See the diff below, hopefully that fixes things for you?
> 
> Bingo, that patch works for me.

Thanks, let me run that through some testing and then I'll post a proper
patch.

> > On a related note, it would be nice if we could make that codegen more
> > readable...  Here were a few formats I had played with before, any
> > thoughts?
> 
> I don't think any of this is ever going to be remotely readable,
> because of the whole horrible section noise.
> 
> If I recall correctly, one of the ideas you had was to use macros to
> make things more legible, but that sadly didn't work with clang or
> something like that?

Right.  Those macros were actually pretty nice.  They worked great with
GCC but Clang wouldn't cooperate.  Maybe I can talk to some Clang people
to try to get that working.

> > Note there's also an objtool "disas" feature Alexandre is working on
> > which will show the disassembly annotated with runtime patching info
> > (alternatives, static branches, etc):
> 
> Yeah, that would be a good feature to have, although I wouldn't
> obviate the asm cleanup for me.
> 
> Depending on what I am looking for, I end up looking at either the asm
> output and the objdump output (or at both) because they each have
> their good and bad parts.
> 
> Sometimes I *want* the comments that gcc in particular adds to the
> assembler, and sometimes I prefer the "raw objdump" format.
> 
> Oh, and Alexandre: if you are working on improving objdump - are you
> perhaps also looking at making the relocation output saner?

Just to clarify, Alexandre is working on objTOOL, not objDUMP :-)

> Because I absolutely detest the odd relocation output format. I use it
> occasionally, but it's just crazy to see things like
> 
> <delayed_put_task_struct>:
>         ...
>         call   <delayed_put_task_struct+0x1a>
>                         R_X86_64_PLT32  rethook_flush_task-0x4
> 
> when any *sane* tool would just output the simple
> 
>         call   rethook_flush_task
> 
> instead.  Because as it is, the line without the relocation info is
> useless, and then the separate relocation line (with -r) is just
> crazy.

FWIW, this can be slightly improved by adding '-w' (objdump -drw) which
at least puts the function name on the same line:

     call   34d <delayed_put_task_struct+0x1d>       349: R_X86_64_PLT32     rethook_flush_task-0x4

The good news is that we will have the ability to print things however
we want with "objtool disas".

-- 
Josh