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: <20241219225642.ho42z3kgeuy5vq4v@jpoimboe>
Date: Thu, 19 Dec 2024 14:56:42 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Brendan Jackman <jackmanb@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v2 0/2] objtool: Add option to fail build on vmlinux
 warnings

On Thu, Dec 19, 2024 at 03:19:13PM -0700, Nathan Chancellor wrote:
> I do agree with you that figuring our the root problem and resolution to
> some of these warnings is not always the easiest, especially when they
> are on the toolchain side, so I have often kicked the can down the road.
> I know there is some documentation in objtool.txt around various
> warnings, is that pretty up to date/accurate? Are there any other
> resources I could look at to help with this work?

I think the document is pretty up to date.  Some warnings are self
explanatory but others like "unreachable instruction" or "stack state
mismatch" do require digging.

One thing that can help is to "export OBJTOOL_VERBOSE=1", which will
tell objtool to disassemble any affected functions and show a backtrace
with all the taken branches leading up to the warning (if applicable).
Maybe that should be the default for --Werror.

I'd definitely like more people to be able to debug objtool warnings.
Any ideas on making that easier or educating people or improving
warnings are very welcome.  I'll be keeping that in mind when looking at
the build errors over the holidays.

> Some objtool reports get sent to only llvm@...ts.linux.dev when clang is
> involved (due to a historical filter IIRC, I cannot find the original
> request), so you may want to glance at [2] to see if anything new pops
> up.

We need to figure out how to get that fixed, the commit author really
needs to know if their code causes a warning/error.

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ