Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite Linux syscalls generation #21440

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

The-King-of-Toasters
Copy link
Contributor

Changes by Arnd Bergmann have migrated all supported architectures to use a table for their syscall lists. This removes the need of calling a C pre-processor and simplifies the logic dramatically.
The side effect is the number of names changed on targets that use the "generic" table. That list (located under scripts/syscall.tbl) adds the _time64 suffix to syscalls taking a timespec64 on 32-bit targets. Similarly, the _time32 suffix has been removed.

The result is a lot of breakage in our Linux wrappers, which makes me worried that the logic for determining the proper timespec to use was subtly broken all this time. Should be a good chance to finish #4726 - we only have 14 years after all...

Changes by Arnd Bergmann have migrated all supported architectures to
use a table for their syscall lists. This removes the need of calling a
C pre-processor and simplifies the logic dramatically.
The generic syscall table has different names for syscalls that take a
timespec64 on 32-bit targets, in that it adds the `_time64` suffix.
Similarly, the `_time32` suffix has been removed.

I'm not sure if the existing logic for determining the proper timespec
struct to use was subtly broken, but it should be a good chance to
finish ziglang#4726 - we only have 14 years after all...

In other news:

- x86_64 gets `uretprobe`, a syscall to speed up returning BPF probes.
- Hexagon gets `clone3`, but don't be fooled: it just returns ENOSYS.
@alexrp
Copy link
Contributor

alexrp commented Sep 18, 2024

The result is a lot of breakage in our Linux wrappers, which makes me worried that the logic for determining the proper timespec to use was subtly broken all this time.

This situation is highly confusing because timespec and kernel_timespec are not the same thing, and the latter is usually what you want. But yes, the time stuff needs to be cleaned up and the standard library probably just wholesale switched to time64. (I can't think of a good reason why we would want to maintain time32 support?)

@@ -24,676 +24,240 @@ const stdlib_renames = std.StaticStringMap([]const u8).initComptime(.{
.{ "arm_fadvise64_64", "fadvise64_64" },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check if this list is still necessary, and if yes, whether all of the entries are.

@The-King-of-Toasters
Copy link
Contributor Author

Kinda scary that the CI passed 🙃 - do we not test for time overflow?

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