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: <bb36374e-aca2-92e1-209d-1524e31147ab@loongson.cn>
Date: Tue, 26 Nov 2024 18:42:15 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 02/10] objtool: Handle special cases of dead end insn

On 11/26/2024 02:45 PM, Josh Poimboeuf wrote:
> On Fri, Nov 22, 2024 at 12:49:57PM +0800, Tiezhu Yang wrote:
>> There are some "unreachable instruction" objtool warnings when compling
>> with Clang on LoongArch, this is because the "break" instruction is set
>> as dead end due to its type is INSN_BUG in decode_instructions() at the
>> beginning, and it does not set insn->dead_end of the "break" instruction
>> as false after checking ".rela.discard.reachable" in add_dead_ends(), so
>> the next instruction of "break" is marked as unreachable.
>>
>> Actually, it can find the reachable instruction after parsing the section
>> ".rela.discard.reachable", in some cases, the "break" instruction may not
>> be the first previous instruction with scheduling by Machine Instruction
>> Scheduler of LLVM, it should find more times and then set insn->dead_end
>> of the "break" instruction as false.
>>
>> This is preparation for later patch on LoongArch, there is no effect for
>> the other archs with this patch.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
>
> I'm having trouble understanding this commit log, is the problem that
> the compiler is sometimes inserting code between 'break' and the
> unreachable() inline asm?
>
> If so, this sounds like a problem that was already solved for x86 with:
>
>   bfb1a7c91fb7 ("x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm")
>
> Can you check if that fixes it?

I will try, thank you.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ