Add ashetos tag to std.Target #35954

This is almost certainly not right, unless you only support AshetOS on architectures that distinguish between soft float and hard float ABI.

Right now, I compile the applications for Ashet OS for .x86, .riscv32 and .thumb with .eabi, without kernel support for hard float passing.

Technically, i'd need a x86-ashetos-ashetos interface but teaching my kind of syscall/callconv to LLVM sounds like a stupid idea ^-^

Can you elaborate your question? I've used EABI because i knew it would work fairly well on all platforms, but you have more expertise here

eabi/eabihf are intended to distinguish soft/hard float as a stopgap until https://github.com/ziglang/zig/issues/20690 (or some variation thereof) is implemented. (I'm hoping to make some progress on this in the next release cycle.) For architectures that don't have a soft float ABI, we just use none or similar.

riscv32-ashetos-eabi is almost certainly not doing what you want, however, because eabi/eabihf aren't even enough to describe the possible float ABIs on RISC-V. There, we unfortunately pick the ABI based on the presence of the d and f CPU features. The eabi probably just does nothing.

x86-ashetos-eabi might work by accident, but x86 + eabi is not really a tested combination. This is another unfortunate situation where you need to set the soft_float CPU feature for good measure.

Can you clarify why any of this matters for syscalls though? On most/all OSs, whether the userspace ABI uses soft or hard float has no bearing on the kABI.

Ashet OS (right now) uses a callconv(.c) compatible function calls for syscalls (Ashet OS does not require interrupts, and has no memory protection, so syscalls are just function calls).

This means that kernel and userland have to agree on the C calling convention.

But this means i'll have to go forward and start doing a larger refactoring of switching from .c to a well-defined calling convention (which sadly will be .x86_stdcall on x86).

But this also implies that when i compile my kernel for a cpu which supports f/d, and the application is compiled generically, they will fail to pass floats?

That sounds horrible.

@ikskuh wrote in #35954 (comment):

But this means i'll have to go forward and start doing a larger refactoring of switching from .c to a well-defined calling convention (which sadly will be .x86_stdcall on x86).

I don't quite follow how you got from there to here.

@ikskuh wrote in #35954 (comment):

But this also implies that when i compile my kernel for a cpu which supports f/d, and the application is compiled generically, they will fail to pass floats?

Yes. That's one reason among several that making ABI decisions based on presence of CPU features results in a really bad user experience.

I don't quite follow how you got from there to here.

Long story. tl;dr: LLVM neither allows (x86-windows + .x86_sysv nor x86-linux + .sysv_cdecl), which means i can't use either for syscalls in my hosted OS variant (run as os app). The only one that
remains on win and linux is .stdcall.

I wanted to use a well-defined CC for this that isn't .c so it's more ABI triple independent.

That's one reason among several that making ABI decisions based on presence of CPU features results in a really bad user experience.

thought so.

I'm not sure what's the right way forward, i guess we could leave in .eabi until I figure it out better and you introduce the target quadruples

AshetOS shouldn't be added here since you already enforce PIE.

You didn't actually remove this change.

Yep, forgot to git add

It may be a good time to factor this condition into a requiresPie function in target.zig.

This is not necessary; enforcing PIE implies enforcing PIC.

Putting this in the freestanding prong is not necessarily a problem, but it is a bit odd. Why not just add it to the prong below that has most OSs?

We were using one of freestanding or other before iirc