build: Filter rtapi module version scripts to defined symbols only

[grandixximo]

rtapi_app.h unconditionally declares EXPORT_SYMBOL(rtapi_app_main) and EXPORT_SYMBOL(rtapi_app_exit), causing every module to list both names in its generated linker version script. Modules that only implement rtapi_app_main (e.g. hal/components/enum.c) then triggered lld's --no-undefined-version (default since LLD 17, see LLVM D135402):

ld.lld: error: version script assignment of 'global' to symbol
'rtapi_app_exit' failed: symbol not defined

Intersect the exported-name list with the actual defined symbols from nm -g --defined-only so the version script only mentions symbols that are really present in the linked object. Behavior under GNU ld is unchanged (the new list is a strict subset of the previous one), and LLD now accepts the build without needing --undefined-version.

Fixes #3191.

[grandixximo]

@BsAtHome please see if this lines up with your build direction.

[NTULINUX]

Tested on Gentoo with both GCC+BFD and Clang+LLD, cooling.hal and axis load perfectly.

[BsAtHome]

Modules that only implement rtapi_app_main

That quote is the real error.

All components are supposed to export both rtapi_app_main() and rtapi_app_exit(). IMO, you should fix the components instead of the linker script. Just make an empty and add it like:

void rtapi_app_exit() {}

[grandixximo]

@BsAtHome you're right, this is the better fix. enum.tmp is the only object with rtapi_app_main but no rtapi_app_exit I was able to find.

@NTULINUX could you pull this and confirm it builds and runs on your Gentoo setup?

[NTULINUX]

Confirmed, working with Clang+LLD. @andypugh I'd like to get this merged into 2.9 as well since it impossible to build that branch with a full, recent LLVM toolchain.

[BsAtHome]

I think the real problem here has been that the uspace run does not complain when rtapi_app_exit is missing.

In rtapi/uspace_rtapi_app.cc:do_load_cmd() it is not checked that both rtapi_app_main and rtapi_app_exit. Only main is extracted and run. At unload in do_unload_cmd() it is ignored if the exit function is missing.

I think it is necessary to fail hard in do_load_cmd() when the exit function is not present and refuse to load the component with the appropriate error message.

[grandixximo]

I think the real problem here has been that the uspace run does not complain when rtapi_app_exit is missing.

In rtapi/uspace_rtapi_app.cc:do_load_cmd() it is not checked that both rtapi_app_main and rtapi_app_exit. Only main is extracted and run. At unload in do_unload_cmd() it is ignored if the exit function is missing.

I think it is necessary to fail hard in do_load_cmd() when the exit function is not present and refuse to load the component with the appropriate error message.

Agreed, my thinking with the first attempt was misguided, I was implementing a work around to compile non-compliant components, the correct approach is refusing to load and force the component to be compliant.

[BsAtHome]

Right! Now, to be a bit pedantic...

This:

DLSYM<int(*)(void)>(module, "rtapi_app_exit")

should probably read:

DLSYM<void(*)(void)>(module, "rtapi_app_exit")

(int -> void) It is also wrong in the original code (probably copy-paste).

Not that it does matter (much) because the return value is not used anyway. However, the function rtapi_app_exit() is declared void and does not return a value. Therefore, indicating that it would is pure misdirection. Using the int return is correct for rtapi_app_main() because it has a return value.

[grandixximo]

Right! Now, to be a bit pedantic...

@BsAtHome pedantic but entirely correct, the best kind.

Fixed both casts...