Implement va_arg for AArch64 Linux #62207

parched · 2019-06-28T14:04:49Z

WIP. I would like some feedback before I tidy it up and properly verify it.

Is this approach of implementing it in rust instead of an intrinsic fine? I did it this way because it was simpler for me to write and should be simpler to understand. Does it matter that I added a hidden method to VaArgSafe?

cc @dlrobertson, #59625 (@joshtriplett @eddyb @ahomescu)

rust-highfive · 2019-06-28T14:04:53Z

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

dlrobertson · 2019-06-28T14:32:58Z

Is this approach of implementing it in rust instead of an intrinsic fine?

It is something I wanted to experiment with. It certainly is much easier to read and less error prone than src/librustc_codegen_llvm/va_arg.rs

CC #56489

ahomescu · 2019-07-01T05:09:21Z

src/libcore/ffi.rs

+    pub trait VaArgSafe {
+        #[doc(hidden)]
+        #[cfg(not(bootstrap))]
+        unsafe fn __va_arg(ap: &mut super::VaListImpl<'_>) -> Self;


I'm not sure about the double-underscore prefix, wouldn't va_arg_internal be a better name?

It's sealed so va_arg or va_arg_from_list would be fine.

ahomescu · 2019-07-01T05:10:39Z

src/libcore/ffi.rs

    ($($t:ty),+) => {
        $(
            #[unstable(feature = "c_variadic",
                       reason = "the `c_variadic` feature has not been properly tested on \
                                 all supported platforms",
                       issue = "44930")]
-            impl sealed_trait::VaArgSafe for $t {}
+            impl sealed_trait::VaArgSafe for $t {


This patch adds a lot of this boilerplate, I'm wondering if there's a way to cut it down (maybe using the type system).

ahomescu · 2019-07-01T05:11:30Z

src/libcore/ffi.rs

+        ptr::read((self.gr_top as usize).wrapping_add(offs as usize) as *const T)
+    }
+
+    // Rust doesn't support these yet


Would moving this implementation into the compiler (inside src/librustc_codegen_llvm/va_arg.rs) let you implement this?

Actually, are these SIMD types? There are some of those in nightly, even for AArch64.

Yeah it would and allow supporting aggregates in general. What I meant by this comment was rust doesn't support aggregates in variadic functions (yet) so it doesn't need to be implemented.

ahomescu · 2019-07-01T05:17:10Z

src/libcore/ffi.rs

@@ -268,35 +268,86 @@ mod sealed_trait {
               reason = "the `c_variadic` feature has not been properly tested on \
                         all supported platforms",
               issue = "44930")]
-    pub trait VaArgSafe {}
+    pub trait VaArgSafe {


Maybe VaArgSafe should be renamed to something more appropriate, like VaArgType.

ahomescu · 2019-07-01T05:37:56Z

I added some comments (mostly just nitpicks).

eddyb · 2019-07-01T08:58:31Z

src/libcore/ffi.rs

+                unsafe fn __va_arg(ap: &mut VaListImpl<'_>) -> Self {
+                    va_arg(ap)
+                }
+                #[cfg(all(target_arch = "aarch64", not(target_os = "ios"), not(windows)))]


You can put the #[cfg] on the expression inside the body, I think?

Ah yes, I think this is just left over from my first iteration where they had different signatures.

eddyb · 2019-07-01T09:03:51Z

How much complexity is left after all the decision-making based on the type is done?
I'm tempted to suggest all the va_arg logic should be in rustc_target::abi::call, but I'm not sure how to reify the information (or whether the existing ArgType infra is useful at all).

eddyb · 2019-07-01T09:11:12Z

src/libcore/ffi.rs

+        let nreg = (mem::size_of::<T>() as i32 + 7) / 8;
+        self.gr_offs = offs + (nreg * 8);
+        if self.gr_offs > 0 {
+            return self.va_arg_on_stack(); // overflowed reg save area


This reminds me I wanted to change how rustc_target::abi::call works for a long time, and make it compute "designations" such as "on-stack" or "in register, if available, otherwise on-stack", with per-target "resources" (such as general-purpose registers for args/return and floating-point registers etc.), and put all of that together to compute final "assignments", afterwards (and we could even cache the per-type computation).
If we also tracked which registers were being used, that might even help Cranelift (cc @sunfishcode).

The relevant point here is making the per-type information context-free, so that it can be used for both signatures and va_arg.

That sounds ideal but outside my current knowledge/ability. Perhaps I could have a look at that after fixing it this way.

bors · 2019-07-05T07:01:17Z

☔ The latest upstream changes (presumably #62376) made this pull request unmergeable. Please resolve the merge conflicts.

parched · 2019-07-06T13:48:11Z

@eddyb

How much complexity is left after all the decision-making based on the type is done?

Basically just checking whether you've overflowed the number of registers and need to go to the stack save area.

parched · 2019-07-06T18:29:54Z

I've tidied it up a bit and extended the tests a bit which now pass (x.py test log if anyone's interested)

ahomescu · 2019-07-10T03:20:32Z

src/libcore/ffi.rs

    fn va_arg<T: sealed_trait::VaArgSafe>(ap: &mut VaListImpl<'_>) -> T;
 }
+
+#[cfg(all(target_arch = "aarch64", not(target_os = "ios"), not(windows)))]


You could move this to the top of the file.

dlrobertson

After a review of this, this seems like a reasonable way to prototype support for new architectures. It is similar to how va_list-rs implements va_arg. The calculation also seems simple enough to implement in IR if we want to go down that road.

@joshtriplett @eddyb thoughts on implementing va_arg in pure rust? I'm not a fan of the sprawl of va_arg implementations we'd get, but that is the only drawback I can see so far. After this, we'd have some architectures rely on LLVMs va_arg (x86_64), others rely on custom LLVM IR we generate (i686), and then we'd have Aarch64 in libstd. Ultimately I'd like to pick one and try to support them all in one place.

dlrobertson · 2019-07-10T03:17:57Z

src/libcore/ffi.rs

+        {
+            if
+            /* classof(type) != "aggregate" && */
+            mem::size_of::<T>() < reg_size {


nit: spacing. Could you change this comment to something like

FIXME(parched): When aggregate types are supported by `VaList::arg` we should ensure the return type is not an aggregate type before this calculation

dlrobertson · 2019-07-10T03:36:26Z

src/libcore/ffi.rs

+    unsafe fn get_begin_and_end<T>(current_pos: usize, reg_size: usize) -> (usize, usize) {
+        let mut begin = current_pos;
+        if mem::align_of::<T>() > 8 && reg_size == 8 {
+            begin = begin.wrapping_add(15) & !15; // round up


The spec uses -16. Is there a reason to use !15 instead.

dlrobertson · 2019-07-10T04:03:26Z

src/libcore/ffi.rs

+    }
+
+    unsafe fn va_arg_on_stack<T: sealed_trait::VaArgSafe>(stack: &mut *mut c_void) -> T {
+        let (begin, end) = Self::get_begin_and_end::<T>(*stack as usize, 8);


AFAIK this can give us different values than the spec if the stack isn't 8 byte aligned, but I suppose much worse things would be happening if that were the case.

eddyb · 2019-07-11T13:19:03Z

Basically just checking whether you've overflowed the number of registers and need to go to the stack save area.

In that case, you should be able to make this pretty general by having an int/float register decision based on the type and then emitting the appropriate IR.
But I'll look at the implementation, maybe we can punt on the ideal solution.

eddyb · 2019-07-11T13:21:50Z

src/libcore/ffi.rs

+        ptr::read(begin as *const T)
+    }
+
+    unsafe fn va_arg_gr_or_vr<T: sealed_trait::VaArgSafe>(


I would rename this to va_arg_reg.

eddyb · 2019-07-11T13:22:39Z

src/libcore/ffi.rs

+        *r_offs = end as i32;
+        if *r_offs > 0 {
+            return Self::va_arg_on_stack(stack); // overflowed reg save area
+        }


Wouldn't it be possible to do this check only once?

eddyb

r=me with @dlrobertson's, @ahomescu's and my nits

hdhoang · 2019-07-26T00:46:09Z

Ping from triage @parched, could you implement the reviewers' comments?

JohnCSimon · 2019-08-03T04:47:51Z

Pinging again @parched can you please address this? Thanks.
@kennytm

kennytm · 2019-08-03T06:23:18Z

r? @eddyb

parched · 2019-08-03T07:14:36Z

Sorry, just on holiday at the moment, but will get on to it this coming week.

parched · 2019-08-16T06:49:51Z

Closing for now, until I have time to come back to this, hopefully that will be next week.

rust-highfive assigned kennytm Jun 28, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 28, 2019

ahomescu reviewed Jul 1, 2019

View reviewed changes

eddyb reviewed Jul 1, 2019

View reviewed changes

Implement va_arg for AArch64 Linux

daa7185

parched force-pushed the va-args branch from e0a5b40 to daa7185 Compare July 6, 2019 18:25

parched marked this pull request as ready for review July 6, 2019 18:30

dlrobertson mentioned this pull request Jul 10, 2019

[WIP] Enable va_arg for raw pointers to unsized types #61126

Closed

ahomescu reviewed Jul 10, 2019

View reviewed changes

dlrobertson reviewed Jul 10, 2019

View reviewed changes

eddyb reviewed Jul 11, 2019

View reviewed changes

eddyb approved these changes Jul 11, 2019

View reviewed changes

hdhoang added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 26, 2019

rust-highfive assigned eddyb and unassigned kennytm Aug 3, 2019

parched closed this Aug 16, 2019

This was referenced Oct 22, 2019

Tier 1 goal: Test Rust natively on Arm with Travis CI rust-embedded/wg#385

Closed

Tier 1 goal: Test Rust natively on Arm with Travis CI rust-lang/infra-team#34

Closed

JamieCunliffe mentioned this pull request May 20, 2020

run-make-fulldeps/c-link-to-rust-va-list-fn fails on aarch64-linux-gnu #56475

Open

workingjubilee added the F-c_variadic `#![feature(c_variadic)]` label Jun 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement va_arg for AArch64 Linux #62207

Implement va_arg for AArch64 Linux #62207

parched commented Jun 28, 2019

rust-highfive commented Jun 28, 2019

dlrobertson commented Jun 28, 2019

ahomescu Jul 1, 2019

eddyb Jul 1, 2019

ahomescu Jul 1, 2019

ahomescu Jul 1, 2019 •

edited

Loading

ahomescu Jul 1, 2019

parched Jul 6, 2019

ahomescu Jul 1, 2019

ahomescu commented Jul 1, 2019

eddyb Jul 1, 2019

parched Jul 6, 2019

eddyb commented Jul 1, 2019

eddyb Jul 1, 2019

parched Jul 6, 2019

bors commented Jul 5, 2019

parched commented Jul 6, 2019

parched commented Jul 6, 2019

ahomescu Jul 10, 2019

dlrobertson left a comment

dlrobertson Jul 10, 2019

dlrobertson Jul 10, 2019

dlrobertson Jul 10, 2019

eddyb commented Jul 11, 2019

eddyb Jul 11, 2019

eddyb Jul 11, 2019

eddyb left a comment

hdhoang commented Jul 26, 2019

JohnCSimon commented Aug 3, 2019

kennytm commented Aug 3, 2019

parched commented Aug 3, 2019

parched commented Aug 16, 2019

Implement va_arg for AArch64 Linux #62207

Implement va_arg for AArch64 Linux #62207

Conversation

parched commented Jun 28, 2019

rust-highfive commented Jun 28, 2019

dlrobertson commented Jun 28, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahomescu Jul 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahomescu commented Jul 1, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb commented Jul 1, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Jul 5, 2019

parched commented Jul 6, 2019

parched commented Jul 6, 2019

Choose a reason for hiding this comment

dlrobertson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb commented Jul 11, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb left a comment

Choose a reason for hiding this comment

hdhoang commented Jul 26, 2019

JohnCSimon commented Aug 3, 2019

kennytm commented Aug 3, 2019

parched commented Aug 3, 2019

parched commented Aug 16, 2019

ahomescu Jul 1, 2019 •

edited

Loading