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: <145fe5b9-59a1-4b70-a7f0-ff353f311cb2@oracle.com>
Date: Wed, 10 Dec 2025 08:53:21 +0100
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Guenter Roeck <linux@...ck-us.net>,
        "Maciej W. Rozycki"
 <macro@...am.me.uk>
Cc: alexandre.chartre@...cle.com, 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/10/25 06:08, Guenter Roeck wrote:
> 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.


test-disassembler-init-styled.c tests that init_disassemble_info() has four
arguments. If this fails then this means that it has only three args and in
that case enum disassembler_style is not defined, and the build should be done
without defining DISASM_INIT_STYLED.

init_disassemble_info() was changed from 3 args to 4 args by the following
binutils change, and enum disassembler_style was introduced at the same time:

   https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=60a3da00bd5407f07

This change has caused the Linux build to fail, and this was fixed by commit
a45b3d6926231 ("tools include: add dis-asm-compat.h to handle version differences")
which introduced dis-asm-compat.h

Can you check that init_disassemble_info() is declared with only 3 arguments
in your dis-asm.h file? (/usr/include/dis-asm.h).

dis-asm.h should either:

- declare init_disassemble_info() with 3 args and not define enum disassembler_style

or

- declare init_disassemble_info() with 4 args and define enum disassembler_style


alex.