You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @bjorn3 , now that c_variadic is stable in rustc,I am looking at unblocking this in cg_clif and wanted to check the approach before a big diff. The plan is to stop fatal ing on variadic function definitions and wire the ... parameter in the function prelude the same way LLVM does by allocating a VaList and running va_start, implement va_arg by porting the arch specific logic from rustc_codegen_llvm/src/va_arg.rs, and implement va_start ourselves since we can't use llvm.va_start while va_end and va_copy can keep using the existing Rust fallback bodies. The hard part is the variadic callee prologue because Cranelift doesnot save incoming argument registers into a reg save area the way LLVM does, so on targets like x86_64 Linux we probably need to spill GP and SSE arg regs at function entry likely via the same inline asm path cg_clif already uses before va_arg can read register passed variadic args. I would start with x86_64 unknown-linux-gnu then expand to ptr fallback targets and AArch64. Does that match what you had in mind or is there a preferred order or something you would rather see done differently like waiting on 'Cranelift variadic' support?
I would strongly prefer proper Cranelift side support. The inline asm call path doesn't handle many important parts of the C ABI like struct arguments.
Activity
0xmuon commentedon Aug 11, 2026
Hi @bjorn3 , now that
c_variadicis stable in rustc,I am looking at unblocking this incg_clifand wanted to check the approach before a big diff. The plan is to stop fatal ing on variadic function definitions and wire the...parameter in the function prelude the same way LLVM does by allocating aVaListand runningva_start, implementva_argby porting the arch specific logic fromrustc_codegen_llvm/src/va_arg.rs, and implementva_startourselves since we can't usellvm.va_startwhileva_endandva_copycan keep using the existing Rust fallback bodies. The hard part is the variadic callee prologue because Cranelift doesnot save incoming argument registers into a reg save area the way LLVM does, so on targets like x86_64 Linux we probably need to spill GP and SSE arg regs at function entry likely via the same inline asm pathcg_clifalready uses beforeva_argcan read register passed variadic args. I would start with x86_64 unknown-linux-gnu then expand to ptr fallback targets and AArch64. Does that match what you had in mind or is there a preferred order or something you would rather see done differently like waiting on 'Cranelift variadic' support?bjorn3 commentedon Aug 11, 2026
I would strongly prefer proper Cranelift side support. The inline asm call path doesn't handle many important parts of the C ABI like struct arguments.