s390x: Initial commit

[joe-lawrence]

Add a snapshot of s390x objfiles currently available in kpatch repo.

compiler: gcc-11.2.1-2.3.el9.s390x, custom w/backports from upstream:
a1c1b7a888ad 0990d93dd8a4
kernel: 5.14.0-2.el9.s390x

TODO:

Integration tests object files not yet included:
cmdline-string.patch
gcc-isra.patch
gcc-mangled-3.patch
meminfo-init2-FAIL.patch
module.patch
new-globals.patch
parainstructions-section.patch
shadow-newpid.patch
symvers-disagreement-FAIL.patch
warn-detect-FAIL.patch

Signed-off-by: Joe Lawrence [email protected]

[joe-lawrence]

To complement dynup/kpatch#1203, we would like a set of object files for unit testing.

@sm00th : I have the entire set of integration test object files saved, should I include all of them, even cmdline-string.o? The other arches didn't, so I wasn't sure what should make the cut.

Also, I don't think dynup/kpatch#1203 implements s390x WARN() detection... my very brief testing of WARN() and might_sleep() doesn't encode line numbers. Should we add this later if and when we encounter such macro for this arch?

Finally, there are a lot of additional functions modified on s390x. I didn't inspect all of them, but I did see a lot of __s390_indirect_jump_rX type changes. Would it be better to filter these out, or just list them in the .test files as I have done. Thanks.

[sm00th]

To complement dynup/kpatch#1203, we would like a set of object files for unit testing.

@sm00th : I have the entire set of integration test object files saved, should I include all of them, even cmdline-string.o? The other arches didn't, so I wasn't sure what should make the cut.

I can't remember why cmdline patch is not there, might be because it is trivial. Porting over as much of tests we have on x86 as we can is a good start.

Also, I don't think dynup/kpatch#1203 implements s390x WARN() detection... my very brief testing of WARN() and might_sleep() doesn't encode line numbers. Should we add this later if and when we encounter such macro for this arch?

Yes, we just need to try and not forget to add the tests once we add this functionality.

Finally, there are a lot of additional functions modified on s390x. I didn't inspect all of them, but I did see a lot of __s390_indirect_jump_rX type changes. Would it be better to filter these out, or just list them in the .test files as I have done. Thanks.

I think it is better to not filter things out so that we are aware if our handling of those inadvertently changes.

[joe-lawrence]

• updated with remaining integration test object files, at least the ones that build and only comprise a single .o file (a few integration tests generate multiple files)