[PowerPC64] Don't mark module data as static on PowerPC64 - Fixes panic when loading ipfw.ko and if_epair.ko built with modern compiler.

[alfredo]

Summary

Similar to arm64 and riscv, when using a modern compiler (!gcc4.2), code generated tries to access data in the wrong location, causing kernel panic (data storage interrupt trap) when loading if_epair and ipfw.

Issue was reproduced with kernel/module compiled using gcc8 and clang8. It affects both ELFv1 and ELFv2 ABI environments.

PR: 232387

Test Plan

Load/Unload if_epair.ko manually
Run FreeBSD TestSuite

[jhibbits]

This change will probably also be needed for DPCPU. Can that be tested as well?

[alfredo]

Same affects DPCPU too and makes ipfw.ko crash during load.
Patch updated fixing this module as well

[bz]

Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?

[alfredo]

In D20461#445840, @bz wrote:

Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?

Yes. Interestingly, modifying D17512 to apply for powerpc64, kernel won't panic anymore but module loading is aborted with error message complaining about missing paddings.

[jhibbits]

We should probably evaluate D17512 again for this at some point, but you demonstrated as-is it's not the complete fix for this problem.

[alfredo]

Is it ok to merge?
This change should close https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232387 as well.