[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH rust-libc] i386-gnu: Add GNU/Hurd os

From: Sergey Bugaev
Subject: Re: [PATCH rust-libc] i386-gnu: Add GNU/Hurd os
Date: Mon, 10 Jul 2023 12:51:15 +0300

On Sun, Jul 9, 2023 at 1:06 PM Damien Zammit <damien@zamaudio.com> wrote:
> Autogenerated mod.rs in 2021 with:
> bindgen input.h -- --sysroot=./hurd-headers -I./hurd-headers/include \
>         -I./hurd-headers/include/i386-gnu -target i386-gnu > mod.rs

I realize this is autogenerated and not written by you, but:

> diff --git a/src/unix/hurd/mod.rs b/src/unix/hurd/mod.rs
> new file mode 100644
> index 000000000..676ea2515
> --- /dev/null
> +++ b/src/unix/hurd/mod.rs
> @@ -0,0 +1,2626 @@
> +//! Definitions for GNU/Hurd i386

Should it be in an arch-specific file then, and not just src/unix/hurd/mod.rs?

> +pub const _AIO_H: u32 = 1;
> +pub const _FEATURES_H: u32 = 1;

Do we really want to export the header guard macros? :)

Perhaps dropping everything that starts with an underscore would be a
good approximation of which definitions should be skipped.

> +pub const _DEFAULT_SOURCE: u32 = 1;

This was not built with _GNU_SOURCE, was it? Should it be?

My understanding is that _GNU_SOURCE and other guards are mostly
useful to avoid cluttering the "user's namespace" with additional
definitions that could conflict with the user's own definitions. This
is not a concern for Rust, so we might as well export everything.

> +extern "C" {
> +    pub static __pthread_errorcheck_mutexattr: __pthread_mutexattr;
> +}
> +extern "C" {
> +    pub static __pthread_recursive_mutexattr: __pthread_mutexattr;
> +}

What about symbol versioning?

How is this supposed to work in general? In C, if I change a glibc
ABI, I'd make a new symbol version, and make the old version a
compatibility shim. So programs compiled against the old headers will
reference the old one, and ones rebuilt against the new headers will
get the new one. With Rust and bindings like these, the ABI / headers
are defined here, mirroring glibc headers at the time of writing. If
the glibc headers change incompatibly, this will not pick it up, even
if you build against the new version of glibc. So you will get the new
symbols but the old ABI, and bad things will happen, certainly not the
kind of things you'd want to happen when writing Rust.

This is not a theoretical concern (although it's not Hurd-specific),
glibc does change ABI, and symbol versioning exists for a reason.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]