Use a template assembly file to generate the embedded MFS.

[jhb]

Summary

This uses the .incbin directive to pull in the MFS image contents.
Using assembly directly ensures that symbols can be defined with the
name and properties (such as .size) desired without having to rename
symbols, etc. via a second objcopy invocation. Since it is compiled
by the C compiler driver, it also avoids the need for all of the
EMBEDFS* make variables.

Suggested by: jrtc27
Obtained from: CheriBSD

Test Plan

• tried to boot a RISC-V kernel with an MFS image but it panicked early because the larger kernel overlapped with the FDT, but it did build and link ok

[kib]

sys/dev/md/embedfs.S

35 ↗

(On Diff #78221)

Does this work on ARM ? AFAIR '@' is comment and the syntax is %progbits

[jrtc27]

sys/dev/md/embedfs.S

35 ↗

(On Diff #78221)

No it doesn't, but %progbits is supported syntax on all architectures I believe and is easier than having a macro that each arch has to define.

[jhb]

• Appease ARM.

[jhb]

I built both RISC-V and ARM (ARMADA38X with MD_ROOT enabled) kernels with this version. We use '%' in the ELF note assembly files for the same reason.

[markj]

sys/conf/kern.post.mk

472 ↗

(On Diff #78289)

How does __mfs_root_size get defined in the new scheme?

[jrtc27]

sys/conf/kern.post.mk

472 ↗

(On Diff #78289)

It doesn't, but that is never used. Even _binary_foo_size is unused in the kernel; everything subtracts _binary_foo_start from _binary_foo_end, because using symbols whose values are sizes not addresses is not really compatible with a lot of code models (and is something that should never have been done in the first place, IMO, yet people still love to do it with fancy linker scripts...).

[markj]

It might be nice to generalize this a bit further to make it easy to embed arbitrary files within the kernel. There's nothing about embedfs.S that's really specific to MFS except the symbol names, I think. For a past project I've used a similar trick to embed a second kernel that gets launched upon a panic to dump memory without requiring a dedicated dump device.

sys/conf/kern.post.mk

472 ↗

(On Diff #78289)

I see, thanks.

[jhb]

In D26781#597781, @markj wrote:

It might be nice to generalize this a bit further to make it easy to embed arbitrary files within the kernel. There's nothing about embedfs.S that's really specific to MFS except the symbol names, I think. For a past project I've used a similar trick to embed a second kernel that gets launched upon a panic to dump memory without requiring a dedicated dump device.

I'm not quite sure how to generalize it, per se, though perhaps one could pass the symbol name (mfs_root) via -DSYMBOL or some such on the command line. I would like to switch the firmware stuff over to this as that removes another case where linkers have to have special code (the firmware bits use ld directly rather than objcopy).

sys/conf/kern.post.mk

472 ↗

(On Diff #78289)

I think in theory one could even now use sizeof(foo) due to the .size directive but I haven't tried that.

[jrtc27]

sys/conf/kern.post.mk

472 ↗

(On Diff #78289)

No, sizeof is done at the language level when you compile the translation unit.

[markj]

In D26781#597815, @jhb wrote:

In D26781#597781, @markj wrote:

It might be nice to generalize this a bit further to make it easy to embed arbitrary files within the kernel. There's nothing about embedfs.S that's really specific to MFS except the symbol names, I think. For a past project I've used a similar trick to embed a second kernel that gets launched upon a panic to dump memory without requiring a dedicated dump device.

I'm not quite sure how to generalize it, per se, though perhaps one could pass the symbol name (mfs_root) via -DSYMBOL or some such on the command line.

That's more or less what I had in mind. Alternately the stub could be generated using a parameterized awk script.

[jhb]

In D26781#597818, @markj wrote:

In D26781#597815, @jhb wrote:

In D26781#597781, @markj wrote:

It might be nice to generalize this a bit further to make it easy to embed arbitrary files within the kernel. There's nothing about embedfs.S that's really specific to MFS except the symbol names, I think. For a past project I've used a similar trick to embed a second kernel that gets launched upon a panic to dump memory without requiring a dedicated dump device.

I'm not quite sure how to generalize it, per se, though perhaps one could pass the symbol name (mfs_root) via -DSYMBOL or some such on the command line.

That's more or less what I had in mind. Alternately the stub could be generated using a parameterized awk script.

I think if I get around to replacing the objcopy/ld hack in fw_stub.awk, then I will see at that time if I can refactor if I can reuse a generalized version for that case.