abis/mlibc: make struct sigaction and siginfo_t match linux ABI #594
Conversation
64
force-pushed
the
signal-abi
branch
5 times, most recently
from
66c0915
to
e7677bf
Compare
| #define si_pid __si_fields.__si_common.__first.__piduid.si_pid | ||
| #define si_uid __si_fields.__si_common.__first.__piduid.si_uid | ||
| #define si_status __si_fields.__si_common.__second.__sigchld.si_status | ||
| #define si_utime __si_fields.__si_common.__second.__sigchld.si_utime | ||
| #define si_stime __si_fields.__si_common.__second.__sigchld.si_stime | ||
| #define si_value __si_fields.__si_common.__second.si_value | ||
| #define si_addr __si_fields.__sigfault.si_addr | ||
| #define si_addr_lsb __si_fields.__sigfault.si_addr_lsb | ||
| #define si_lower __si_fields.__sigfault.__first.__addr_bnd.si_lower | ||
| #define si_upper __si_fields.__sigfault.__first.__addr_bnd.si_upper | ||
| #define si_pkey __si_fields.__sigfault.__first.si_pkey | ||
| #define si_band __si_fields.__sigpoll.si_band | ||
| #define si_fd __si_fields.__sigpoll.si_fd | ||
| #define si_timerid __si_fields.__si_common.__first.__timer.si_timerid | ||
| #define si_overrun __si_fields.__si_common.__first.__timer.si_overrun | ||
| #define si_ptr si_value.sival_ptr | ||
| #define si_int si_value.sival_int | ||
| #define si_call_addr __si_fields.__sigsys.si_call_addr | ||
| #define si_syscall __si_fields.__sigsys.si_syscall | ||
| #define si_arch __si_fields.__sigsys.si_arch |
There was a problem hiding this comment.
These defines are incredibly ugly. Can't we use anonymous unions and structs to avoid this mess?
There was a problem hiding this comment.
Anonymous unions and structs are a C11 feature, right?
There was a problem hiding this comment.
Then I don't see a particularly better way than using these defines.
64
force-pushed
the
signal-abi
branch
2 times, most recently
from
1aed8a1
to
fda6cd5
Compare
|
Overall, I'm not convinced that this is a good change. All OSes that currently use this ABI will need to be changed (which OSes are affected?). What do they gain by doing that? Also, what do they gain over simply using |
|
Well currently our |
|
I wouldn't be opposed to deleting this in favour of abis/linux either, tbh. |
|
Well, it's one issue to change Managarm, but this also affects Ironclad. If only Managarm wants to change, we can easily switch Managarm to |
|
That's true: if they want to change to use |
Fixes #257. Fixes #590. Obsoletes #463.