RTAI: Fix undefined symbols in hal_lib

[NTULINUX]

I am not sure if the code is correct, just some simple copy and paste.

[andypugh]

This is pretty much what I was planning to do, but was hoping for Petter to chip in.

[petterreinholdtsen]

[Andy Pugh]

This is pretty much what I was planning to do, but was hoping for Petter to chip in.

Given that I do not really know the inner working of the HAL library, all I can say that the code seem sensible to me. Perhaps the commit message could explain what is giving the undefined symbols issue, so the rest of us understand the context?

…

-- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

Btw, perhaps you can include a script in tests/ triggering the problem and validating that the patch do as intended? -- Happy hacking Petter Reinholdtsen

[andypugh]

Btw, perhaps you can include a script in tests/ triggering the problem and validating that the patch do as intended?

I don't think that there is any need for that, as almost every existing test fails at the point that it tries to create a HAL pin (not specifically a 64-bit one).
But only in kernel-mode RTAI.

[NTULINUX]

Btw, perhaps you can include a script in tests/ triggering the problem and validating that the patch do as intended?

I don't think that there is any need for that, as almost every existing test fails at the point that it tries to create a HAL pin (not specifically a 64-bit one). But only in kernel-mode RTAI.

Wonderful.. Is there a way to add some debug info into creating HAL pins, maybe a way to track down how/why it's failing?

[andypugh]

Wonderful.. Is there a way to add some debug info into creating HAL pins, maybe a way to track down how/why it's failing?

What seems to be the situation here is that the patch as-installed exports symbols for the 64-bit parameter creation function, but does not contain the code, so there is no compiled code for the function to link to.

This appears to be OK for a .so and at compile time doesn't raise an error for a .ko either. (This is probably reasonable, in many cases the function body is compiled and linked at a different point in the process).
However, when you load a .so it looks like there is no check that the exported function has code to call. But with a ,ko there is.

This won't have shown up as, at the moment, no HAL components attempt to create a 64-bit HAL parameter. I think that if one were to write a test ,comp that tries to create a 64-bit param, then there would be a compilation failure. I probably need to reboot to uspace to check.