On Thu, Jan 30, 2025 at 04:55:39PM +0100, Brendan Jackman wrote: > On Tue, 14 Jan 2025 at 01:14, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > Thanks! I'm putting it through bot testing now. > > Hey Josh, how has it been going - could we merge the feature? > > (Or, has it already been merged in some tree that doesn't go into linux-next?) It looks like it is in Josh's tree but that tree does not flow into -next; IIRC, they have to be merged into -tip to show up there. https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool/core For the record, this will be disruptive for clang users because a number of warnings have crept up in recent releases and this option will get enabled for allmodconfig. I have started going through them all but I am working at an unfortunate intersection between compiler/optimization internals, other flags such as sanitizers, and reconstructing control flow. Most of them are "falls through to the next function" or "unexpected end of section" warnings, which generally mean some undefined behavior has been encountered and clang has given up code generation. Figuring out what changed on the LLVM side requires a bisect then reporting it (if it is a legitimate compiler problem) requires a source file reduction. I did explore turning unreachable into a trap to fix several of those but I think that will need further objtool changes to cure the warnings that were reported: https://lore.kernel.org/all/?q=llvm-trap-unreachable I think Josh already mentioned it but exposing -Werror for objtool is a big committment. Any time the build breaks because of it (even due to external factors such as a compiler upgrade), there will be a need for triage and just saying "turn off CONFIG_OBJTOOL_WERROR" cannot always be the solution otherwise it loses its power. While it is nice leverage to keep things clean (and I feel like it has generally worked well for compilers with CONFIG_WERROR), it is disruptive and requires real labor to upkeep, which should be from the authors who introduce the warnings but they might need guidance or advice. I am regularly helping people with figuring out issues from the LLVM toolchain becuase they get a report that they have broken something but they do not use LLVM so they are unsure what to do or what it means. I am not saying this is all a bad idea but I want to make sure that this committment has been considered. If exposing this to the world feels too premature, maybe the flag could be added then have a make variable like OBJTOOL_FLAGS to allow a developer to pass it through if they wish? Cheers, Nathan
