On Thu, Dec 19, 2024 at 02:56:42PM -0800, Josh Poimboeuf wrote: > 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. Yeah, that does not sound like a bad idea. If the build is going to break, it seems reasonable to give developers as much pertinent information as possible so they can address the problem properly and move on. > 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. I will definitely ponder on that as well since I should have a good perspective on that front. > > Some objtool reports get sent to only llvm@xxxxxxxxxxxxxxx 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. I have started a new thread with the 0day folks to get that adjusted with you and Peter on CC: https://lore.kernel.org/20241220200617.GA936171@ax162/ Cheers, Nathan
