linux-kernel - Re: [PATCH v6 03/30] objtool: Disassemble code with libopcodes instead of running objdump

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: <60c5972a-5ee5-4d9a-b71c-f2645f834dd0@roeck-us.net>
Date: Tue, 9 Dec 2025 21:08:24 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: "Maciej W. Rozycki" <macro@...am.me.uk>,
 Alexandre Chartre <alexandre.chartre@...cle.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
 jpoimboe@...nel.org, peterz@...radead.org, david.laight.linux@...il.com
Subject: Re: [PATCH v6 03/30] objtool: Disassemble code with libopcodes
 instead of running objdump

On 12/9/25 14:25, Maciej W. Rozycki wrote:
> On Tue, 9 Dec 2025, Alexandre Chartre wrote:
> 
>>> Bisect log is attached. I see the problem with gcc 11.4.0, 13.3.0, and
>>> 14.3.0. I tried with both Ubuntu 22.04 and 24.04.
>>
>> This sounds like a configuration issue depending on the binutils version; in
>> particular the setting of DISASM_INIT_STYLED (although that's supposed to be
>> automatically configured by tools/objtool/Makefile).
> 
>   I only came across these patches now.
> 
>   As attractive as it may seem how is this stuff supposed to fly given that
> binutils internal libraries promise no stable API to out-of-tree software.
> The interfaces can change anytime, just as it is with our internals.
> 
>   Wouldn't it make sense to improve objdump instead so as to provide the
> features required?
> 
>   Also is it actually legal to link objtool and libopcodes together, given
> that they are GPLv2 and GPLv3 respectively?
> 
>   FWIW asking as one of the binutils contributors and port maintainers.
> 

After some more digging I found that the version of binutils installed in
the system determines if the build error is seen or not. So I can have
a toolchain with the latest binutils version, but the build still fails if
the binutils version installed in the system is too old. 2.38 (as in
Ubuntu 22.04) is too old since it does not define 'enum disassembler_style'
in dis-asm.h. As far as I can see that enum was only introduced with
binutils 2.39.

Now the problem is that DISASM_INIT_STYLED is evaluated with
tools/build/feature/test-disassembler-init-styled.c, which checks for
the existence of struct disassemble_info (not the enum). AFAICS that
structure was introduced with binutils-2_18.

Unless my analysis is wrong that means that Linux will now fail to build
on systems with binutils 2.18 ... 2.38 installed.

Guenter