Lower x86-interrupt byval first argument as pointer

[Dnreikronos]

Fixes #833

An extern "x86-interrupt" function can have a by-value first Rust argument, such as i64 or a by-value struct. rustc's LLVM backend lowers that first byval stack argument to a pointer-shaped backend parameter for x86_intrcc.

GCC's interrupt attribute expects the same pointer-shaped first parameter. Without that lowering, libgccjit reports interrupt service routine should have a pointer as the first argument and does not write an object file, which then shows up as a confusing follow-up archive/object error.

Mirror rustc's lowering in the GCC backend for the first x86-interrupt byval argument, while keeping the interrupt attribute. This avoids the libgccjit abort without rejecting a Rust signature that rustc accepts.

The regression test covers scalar and by-value struct first arguments.

[Dnreikronos]

@antoyo, hi mate!
can you help me with this, please?

[antoyo]

Sorry for the delay.
I'll try to review this in the following days.

[Dnreikronos]

Sorry for the delay. I'll try to review this in the following days.

all good!
ty!

[antoyo]

LLVM only warns on the same code.

What is the warning produced by LLVM? (I don't see it.)

One question I have is: is the code in the issue supposed to work correctly, or does Rust also always expect a pointer argument?

[Dnreikronos]

yeah, i checked this again and i think the pr description is a bit off here.

i don't see an llvm warning either. with rustc 1.96.0 / llvm 22.1.2, the testcase compiles cleanly for me. dumping the llvm ir shows rustc lowers the first arg to a pointer/byval param:

define x86_intrcc void ... (ptr byval([8 x i8]) align 8 %_a)

so imo rust is not expecting the rust-level arg itself to be a pointer. it accepts something like i64 or a by-value struct, then lowers it into the pointer shape the backend wants.

tbh i think the better fix is to mirror that lowering in the gcc backend, instead of rejecting the source signature or dropping the interrupt attr. i'll update the pr in that direction.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[antoyo]

@Dnreikronos: Oh it seems my last comment was not sent correctly.
Here it is:

Please add this as a comment (why we add general-regs-only) so that the reasoning stays in the code.
After that, I think we'll be good to merge this.

[antoyo]

@Dnreikronos Did you make any change since my last approval? (I'm asking because you requested another review.)
Is this PR ready to be merged if the CI passes?

[Dnreikronos]

@Dnreikronos Did you make any change since my last approval? (I'm asking because you requested another review.) Is this PR ready to be merged if the CI passes?

I just squashed all the commits to clean the history and be easier to understand everything. And yes, it's ready the be merged when the CI passses

[antoyo]

Thanks for your contribution!