Skip to content

Deprecate uses_fp: always enable FPU state save on all threads#3900

Open
grandixximo wants to merge 3 commits intoLinuxCNC:2.9from
grandixximo:fix/deprecate-uses-fp-2.9
Open

Deprecate uses_fp: always enable FPU state save on all threads#3900
grandixximo wants to merge 3 commits intoLinuxCNC:2.9from
grandixximo:fix/deprecate-uses-fp-2.9

Conversation

@grandixximo
Copy link
Copy Markdown

GCC on x86-64 may emit SSE instructions (e.g. for struct zeroing) even in functions that don't explicitly use floating point. On RTAI, threads created with uses_fp=0 skip FPU/SSE state save/restore, silently corrupting XMM registers of other Linux processes and causing heap corruption and system crashes.

Fix by always enabling FPU state save regardless of the uses_fp parameter:

  • rtai_rtapi.c: always pass 1 to rt_task_init_cpuid
  • hal_lib.c: override uses_fp=0 to 1 in hal_create_thread
  • hal_lib.c: remove addf FP compatibility check (now meaningless)

Emit deprecation warnings when uses_fp=0 is requested.

Ref: #3895

Luca Toniolo added 2 commits April 3, 2026 18:10
GCC on x86-64 may emit SSE instructions (e.g. for struct zeroing)
even in functions that don't explicitly use floating point. On RTAI,
threads created with uses_fp=0 skip FPU/SSE state save/restore,
silently corrupting XMM registers of other Linux processes and
causing heap corruption and system crashes.

Fix by always enabling FPU state save regardless of the uses_fp
parameter:
- rtai_rtapi.c: always pass 1 to rt_task_init_cpuid
- hal_lib.c: override uses_fp=0 to 1 in hal_create_thread
- hal_lib.c: remove addf FP compatibility check (now meaningless)

Emit deprecation warnings when uses_fp=0 is requested.

Ref: LinuxCNC#3895
Minimal doc update for 2.9. Full refactor of component docs,
halcompile, and API removal planned for 2.10.

Ref: LinuxCNC#3895
@grandixximo
Copy link
Copy Markdown
Author

grandixximo commented Apr 3, 2026

@andypugh I was thinking to have minimal docs and code changes for 2.9 just to address the issue directly, minimal impact, small hack but gets 2.9 working on RTAI again.
For 2.10 I will dig deeper in the docs, and the code, to completely rip out uses_fp, this will break compatibility with out of tree .comp and .c components, which we are already planning to do for the 64/32bit refactor.

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

I think this should also include the following (patch is against master; currently cannot easily build 2.9):
halcompile-nofp-fp.diff.txt

This patch changes halcompile to add a warning when you use nofp or fp in function statements. It also fixes all components I could find that did emit the warning. Please adapt to 2.9 branch.

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

A small typo in the warn function. It should always return 1:

def optfp_warn(state):
    s = "nofp" if 0 == state else "fp"
    Warn("'{}' is not longer supported. Threads are always floating point threads.".format(s))
    return 1

The change in the parser rule OptFP should remain in place to call the warning function when the keyword is used. However, to ease the burden on 2.9 users, this may be changed slightly by keeping silent but still force the fp state:

def optfp_warn(state):
    return 1

Add optfp_warn() in halcompile that silently forces fp to 1 when
fp or nofp keywords are used in function declarations. Out-of-tree
.comp files will still parse without error.

Remove fp/nofp from all in-tree .comp files, conv.comp.in template,
and mkconv.sh generator.

Based on patch by BsAtHome.

Ref: LinuxCNC#3895
@grandixximo
Copy link
Copy Markdown
Author

Done with your patch as reference, you are doing 2.10 then? @BsAtHome

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

The man-pages are wrong. You are changing the generated files and not the adoc man-page source in docs/src/man/...

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

Done with your patch as reference, you are doing 2.10 then? @BsAtHome

It is all your pleasure :-)

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

The man-pages are wrong. You are changing the generated files and not the adoc man-page source in docs/src/man/...

Hm, yes, for master branch it is wrong... 2.9 is still of groff life support.

@grandixximo
Copy link
Copy Markdown
Author

grandixximo commented Apr 3, 2026

The man-pages are wrong. You are changing the generated files and not the adoc man-page source in docs/src/man/...

Hm, yes, for master branch it is wrong... 2.9 is still of groff life support.

But this is 2.9, I was searching docs/src/man/
cannot find the adoc in the source.

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented Apr 3, 2026

The man-pages are wrong. You are changing the generated files and not the adoc man-page source in docs/src/man/...

Hm, yes, for master branch it is wrong... 2.9 is still of groff life support.

But this is 2.9, I was searching docs/src/man/ cannot find anything in the source.

That is indeed what I said :-)
Groff is the man-page formatter for the [t]roff format used in 2.9 and earlier. Everything got converted to adoc after 2.9, including components documentation.

@grandixximo
Copy link
Copy Markdown
Author

The man-pages are wrong. You are changing the generated files and not the adoc man-page source in docs/src/man/...

Hm, yes, for master branch it is wrong... 2.9 is still of groff life support.

But this is 2.9, I was searching docs/src/man/ cannot find anything in the source.

That is indeed what I said :-) Groff is the man-page formatter for the [t]roff format used in 2.9 and earlier. Everything got converted to adoc after 2.9, including components documentation.

So we are good, I did it right for 2.9 😌

@grandixximo
Copy link
Copy Markdown
Author

I did not rebuild the .po
should I do that? or not?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants