Linux build: handle CONFIG_OBJTOOL_WERROR=y

[AttilaFueloep]

Motivation and Context

Linux 5.16 by default fails the build on objtool warnings. We have known and understood objtool warnings we can't fix without involving Linux maintainers.

Description

To work around this we introduce an objtool wrapper script which removes the --Werror flag.

How Has This Been Tested?

Manually.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[AttilaFueloep]

If I understand the checkstyle error correctly, it complains that objtool-wrapper.in has a license tag. Not sure how to handle this.

[behlendorf]

Yup, this will work. I've got a little time this afternoon, let me see if I can help wrestle with auto tools to get it to do what we want. In the meanwhile I added a few comments.

[AttilaFueloep]

The second commit is misguided, sorry. I definitely should stop computer work when too tired to think clearly. Especially when working outside my comfort zone.

The last commit should address all issues and improve things. I can squash if preferred.

[behlendorf]

No worries. If you can address my one comment, squash these commits, and update the PR. Then I think this should be all set.

[AttilaFueloep]

Will do.

There's still the checkstyle issue with the license tag. If I'm reading spdxcheck.pl correctly, I'd have to either add scripts/objtool-wrapper.in to $tagged_patterns or remove the tag. I think the former is cleaner so I will do that. Will push a final commit to let the CI do its job and squash when it's done.

[AttilaFueloep]

Rebased and squashed.

[AttilaFueloep]

It doesn't solve the --enable-linux-builtin case

As I see it, we have two options. Ask people to configure the kernel without CONFIG_OBJTOOL_WERROR=y, I think that's reasonable.

Or we can we can patch noreturns.h using configure. To do that we'd have to reactivate the disabled noretun attributes (cd6a579) and put that behind an #ifdef BUILTIN. (Ironically the correct version would produce literally hundreds of warnings when compiled as a module.) Not a big deal and good for correctness.

If we want to take the second approach, there's still lua_error() which is declared as returning int but is noreturn. That would be a bit more invasive. I see that the lua code is mostly untouched, I guess to ease updating. Not sure if there's any policy regarding that.

[AttilaFueloep]

The labels/push failutre is strange. It popped up after a push, seems I hit the wrong key in Magit. Usually I use the terminal for pushing so I've to look into what went went wrong. It complains about not finding .git. I use git work trees which means .git isn't a directory but a file containing a link to the real git dir, maybe that's related?

[behlendorf]

Ask people to configure the kernel without CONFIG_OBJTOOL_WERROR=y, I think that's reasonable.

Yeah, I think so too.

The labels/push failutre is strange. It popped up after a push

I'm pretty sure this is something going wrong in the CI. I'll try and take a look this week.

[AttilaFueloep]

Ask people to configure the kernel without CONFIG_OBJTOOL_WERROR=y, I think that's reasonable.

Yeah, I think so too.

And it's the easiest solution too.

I'm pretty sure this is something going wrong in the CI. I'll try and take a look this week.

All right, thanks.