Correct module symbol export handling

[emaste]

Summary

EXPORT_SYMS can be set to YES, NO, a list of symbols to export from a module, or to a filename containing such a list. For the case that it is set to a symbol list, replace spaces in the list with newlines, so the created file is in the format expected by kmod_syms.awk.

Sponsored by: Turing Robotic Industries Inc.

[imp]

Looks good to me.

[emaste]

Microoptimize away a fork+exec of tr, from @stevek

[jhb]

Looks ok to me. Did you have a test kernel module you used to test this?

[emaste]

In D14284#300389, @jhb wrote:

Looks ok to me. Did you have a test kernel module you used to test this?

I discovered this while trying to test an in-progress arm64 linuxolator port, observed by comparing symbols listed in readelf -s / nm -D with what I expected. I'll see about adding an explicit test module to demonstrate the issue, although the fact that amd64 uses .o kernel modules is a confounding issue.

[jhb]

I was just curious, I don't think there's probably a need to make a test module (though having a real test for this might be nice). I had figured you had run into it somehow and was wondering if that somehow had turned into an easy test to verify correctness. :)

[emaste]

In D14284#300508, @jhb wrote:

I was just curious, I don't think there's probably a need to make a test module (though having a real test for this might be nice). I had figured you had run into it somehow and was wondering if that somehow had turned into an easy test to verify correctness. :)

It's proved difficult to verify end-to-end behaviour, because symbol handling in our kernel loader is somewhat wonky; depending on architecture symbols may come from .dynsym or .symtab.