Modules support for arm64

[kib]

Summary

I have to use shared objects format for modules, instead of relocatable objects, due to limitations in the addressing.

The bug in 2.25.1 binutils requires the hack to avoid ld -r, which eg makes ctfmerge non-functional. I verified that git head for binutils has the issue fixed, but I did not digged exact change that did it.

It seems that the architecture requires -fPIC for shared objects, linker was not able to link modules built without -fPIC.

[andrew]

sys/arm64/arm64/elf_machdep.c

191–192

Used

208

Used

sys/arm64/arm64/trap.c

278 ↗

(On Diff #9126)

This appears to be unrelated (but useful, just commit)

sys/dev/sym/sym_hipd.c

140

Could this be a dmb(ish)?

[kib]

sys/dev/sym/sym_hipd.c

140

I think this driver should be disabled for anything but i386. I have no opinion about ish/sy, in fact, I think that either one is wrong.

[kib]

Remove __unused; some editing to the ld comment. Committed the trap.c assert change.

[kib]

Full context, by emaste request.

[kib]

BTW, after the agreement to use shared objects as the module format is reached, it may be easier to expedite this in two stages. First, elf_machdep.c changes are really straightforward. Then, the sys/conf changes (or hacks, if you so inclined) can be shaped.

[emaste]

sys/arm64/arm64/elf_machdep.c

161

ugh, seems we do this on other archs too. should just return -1 instead?

sys/conf/kern.post.mk

215

Sigh, I wish we didn't need this. But I don't think there's a better way.

sys/conf/kmod.mk

132–135

I think we ought to keep these md parts in (mostly) alpha order

192

We ought to see if this fix made it back to the 2.25 branch and try to get it merged back if not so that we can pick it up with the next binutils port update.

sys/dev/sym/sym_hipd.c

140

Agreed, this has no value on arm64.

sys/modules/Makefile

483

this one could stay in alpha order

[emaste]

BTW, after the agreement to use shared objects as the module format is reached, it may be easier to expedite this in two stages. First, elf_machdep.c changes are really straightforward. Then, the sys/conf changes (or hacks, if you so inclined) can be shaped.

Sounds good to me.

[kib]

sys/arm64/arm64/elf_machdep.c

161

The presence of unknown relocation type practically means that the loaded file is corrupted. There are very high chances that we already applied some relocations, and that relocations can modify arbitrary kernel memory.

Since we detected a blob, which is not of the expected content, and which already polluted kernel address space, I think that the panic is the best reaction.

sys/conf/kern.post.mk

215

This is a consequence of calling the $MACHINE arm64 instead of aarch64. It was a reasonable thing to distinguish between powerpc and powerpc64, but it is not clear that having three names aarch64/armv8/arm64, all of them ortohonal, would serve us usefully in future.

sys/conf/kmod.mk

192

Wouldn't it is wiser to wait for 2.26 and then remove the hack ?

[kib]

Reorder some Makefile hacks.

Also, I added ff copyright for year 2015. Please review the existing copyright holders in the elf_machdep.c. I believe that only Andrew and FF are correct, everything else is copy/paste mistake.

[emaste]

sys/conf/kmod.mk

192

As long as it's going to be arriving in time that makes sense.

[emaste]

In D3796#78662, @kib wrote:

Reorder some Makefile hacks.

Also, I added ff copyright for year 2015. Please review the existing copyright holders in the elf_machdep.c. I believe that only Andrew and FF are correct, everything else is copy/paste mistake.

Yes, it looks like you are correct, this is new work.

[andrew]

I've tested on a HiKey board by both loading modules from loader, and with kldload.

sys/arm64/arm64/elf_machdep.c

210

Why is this needed?

[kib]

Partial commit was done; more to come.