Switch from .init_array constructors to /proc/self/auxv.
#385
Conversation
src/utils.rs
Outdated
| /// misaligned, or pointing to a region of memory that wraps around the address | ||
| /// space. | ||
| #[allow(dead_code)] | ||
| pub(crate) fn check_raw_pointer<T>(value: *const core::ffi::c_void) -> Option<*const T> { |
There was a problem hiding this comment.
For my own knowledge, I'm curious if there is any reason not to use NonNull<T> here so we could pack the Option?
There was a problem hiding this comment.
Only that it hadn't occurred to me :-). But looking into it, NonNull is *mut rather than *const, which is a little inconvenient in src/backend/linux_raw/vdso.rs where it's used a bunch. I'll need to think about this more.
There was a problem hiding this comment.
I've now added a patch to do this. It is a little more verbose, but I think it's ok.
|
Shouldn't this PR call out a lot more loudly that the default has now switched to It seems worth splitting out into a separate preparatory patch even I'd say. |
|
Alternatively, perhaps the implication here due to the indirection implied by a new |
The default is still linux_raw; it's just using libc for the aux values, which isn't user-visible. All It's possible this is a breaking change for |
In the linux_raw backend, switch from using a `.init_array` constructor for obtaining the aux values to reading them from /proc/self/auxv. This avoids problems in situation where other Rust code can run before the constructor, potentially distrupting the `__environ` value. Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature, which enables use of libc to read the aux values, instead of reading them from /proc/self/auxv. The "use-libc-auxv" option is enabled by default, because it's more efficient and doesn't depend on /proc, so it's likely better for most users. Mustang, for its part, continues to be able to use the incoming auxv on the stack because it controls program startup. Since it doesn't have to worry about the hazards of /proc or QEMU, it can trust the incoming values, and do less checking. Fixes #382.
This allows it to pack the return value into a single pointer-sized value.
sunfishcode
force-pushed
the
sunfishcode/proc-self-auxv
branch
from
c41b59d
to
e019fbb
Compare
In the linux_raw backend, switch from using a
.init_arrayconstructorfor obtaining the aux values to reading them from /proc/self/auxv. This avoids
problems in situation where other Rust code can run before the constructor,
potentially distrupting the
__environvalue.Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature,
which enables use of libc to read the aux values, instead of reading
them from /proc/self/auxv.
The "use-libc-auxv" option is enabled by default, because it's more
efficient and doesn't depend on /proc, so it's likely better for most
users.
Mustang, for its part, continues to be able to use the incoming auxv on
the stack because it controls program startup. Since it doesn't have to
worry about the hazards of /proc or QEMU, it can trust the incoming
values, and do less checking.
Fixes #382.