Machinekit rtapi_app process symbol visibility

[ce...@tuta.io]

Hello,
recently, in my play, I ran afoul of the Machinekit-HAL symbol visibility mechanism, where the RTAPI symbols must be post-processed in the output ELF by comparing sections and deleting symbols not defined as an EXPORT_SYMBOL and also the explicit denial of rtapi_app being linked as a -export-dynamic.

(Point: I presume that the userspace RT threads focus is design feature of Machinekit. Not something which happened in the passing.)
I plus/minus do get why the symbol isolation is needed. But why was this form used over own linker namespaces with run-time exported symbols to few important functions?

And how to best "export" few symbols from rtapi_app to other modules given that rtapi_app cannot export any symbols? The best thing I came up with is to create shared library which will be linked both by rtapi_app and given module, given the fact that all live in one linker namespace.

Thanks
Cern.

[John Morris]

On Friday, November 15, 2019 at 6:48:51 AM UTC+8, ce...@tuta.io wrote:

Hello,
recently, in my play, I ran afoul of the Machinekit-HAL symbol visibility mechanism, where the RTAPI symbols must be post-processed in the output ELF by comparing sections and deleting symbols not defined as an EXPORT_SYMBOL and also the explicit denial of rtapi_app being linked as a -export-dynamic.

(Point: I presume that the userspace RT threads focus is design feature of Machinekit. Not something which happened in the passing.)
I plus/minus do get why the symbol isolation is needed. But why was this form used over own linker namespaces with run-time exported symbols to few important functions?

This is actually a relic of the days of kernel threads and integrating with Linux KBUILD.  Hopefully that's enough of a clue to track down your problem, since I've forgotten almost everything else about it.

And how to best "export" few symbols from rtapi_app to other modules given that rtapi_app cannot export any symbols? The best thing I came up with is to create shared library which will be linked both by rtapi_app and given module, given the fact that all live in one linker namespace.

 

Well, `rtapi_app` CAN export symbols, those marked with `EXPORT_SYMBOL`.  To export a few symbols, that's the "best way" because it exists, it works, and other developers are familiar with it.  Why won't it work in your use case?

    John

[ce...@tuta.io]

Nov 18, 2019, 08:27 by jo...@dovetail-automata.com:

>
>
> On Friday, November 15, 2019 at 6:48:51 AM UTC+8, ce...@tuta.io wrote:
>
>> Hello,
>> recently, in my play, I ran afoul of the Machinekit-HAL symbol visibility mechanism, where the RTAPI symbols must be post-processed in the output ELF by comparing sections and deleting symbols not defined as an EXPORT_SYMBOL and also the explicit denial of rtapi_app being linked as a -export-dynamic.
>>
>> (Point: I presume that the userspace RT threads focus is design feature of Machinekit. Not something which happened in the passing.)
>> I plus/minus do get why the symbol isolation is needed. But why was this form used over own linker namespaces with run-time exported symbols to few important functions?
>>
>
> This is actually a relic of the days of kernel threads and integrating with Linux KBUILD.  Hopefully that's enough of a clue to track down your problem, since I've forgotten almost everything else about it.
>

Yes, thank you. I know how it works. I was just thinking if the linker namespaces would not be a better solution. But the problem with GLibC is that nothing younger than 15 years is considered for primetime and so there is (I think) only 16 possible namespaces with no ability to reuse or to insert into.

>
>
>
>> And how to best "export" few symbols from rtapi_app to other modules given that rtapi_app cannot export any symbols? The best thing I came up with is to create shared library which will be linked both by rtapi_app and given module, given the fact that all live in one linker namespace.
>>
>>
>
>  
> Well, `rtapi_app` CAN export symbols, those marked with `EXPORT_SYMBOL`.  To export a few symbols, that's the "best way" because it exists, it works, and other developers are familiar with it.  Why won't it work in your use case?
>

Because there is an executive order not to do it. Look at https://github.com/machinekit/machinekit-hal/blob/120c9f765cf12bcd337b66308b64b3146a26ec8d/src/rtapi/Submakefile#L165-#L180 . So I don't want to do something which goes against basic architectural design of the application.

Cern.

>
>     John
>
>
>
>
> --
> website: > http://www.machinekit.io> blog: > http://blog.machinekit.io> github: > https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to > machinekit+...@googlegroups.com> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com?utm_medium=email&utm_source=footer>> .
>