Syscall arch functions make assumptions about the ABI

[2over12]

The ARMSyscall function assumes a certain set of registers as arguments:

macaw/macaw-aarch32/src/Data/Macaw/ARM/Arch.hs

Line 190 in 54af25d

ARMSyscall :: WI.W 24

The function also references the x86 syscall

macaw/x86/src/Data/Macaw/X86/ArchTypes.hs

Line 808 in 54af25d

X86Syscall :: (1 <= w)

In my opinion these functions should not make assumptions about the system ABI. It makes it quite difficult for downstream consumers to handle ad-hoc non-linux platforms.

The comment references that this is due to the fact that translation does not hold onto current register identity (e.g. issues mentioned in #460)

I firstly am not totally convinced we couldn't just expose and populate these syscalls with more GPRs (at least on arm exposing r0-r14 seems reasonable to me). Secondarily regardless of the technical difficulties this limitations is going to cause some larger issues downstream and it also may be worth going after some solution to #460 to pass the full reg state to syscalls.

Regardless of approach I do think ideally we would lift this restriction

[2over12]

At a minimum something like master...expose-more-regs-in-syscall seems necessary

[RyanGlScott]

Good catch! I agree that we shouldn't be making ABI-specific functions in an ostensibly ABI-agnostic library like macaw (unless otherwise explicitly stated, as in Data.Macaw.X86.SyscallInfo.Linux).

What if we just pass the full register state to ARMSyscall and friends? That feels like the most general solution, and it would future-proof us in case any ABIs' syscalls require things besides general-purpose registers. The flip side is that we'd have to update downstream code in stubs to account for this. For instance, there is some code here in the AArch32 Linux syscall ABI part of stubs which implicitly expects the ARM system call register type to have a specific shape. This code would need to be updated in order to extract the relevant registers instead.

[2over12]

Im wondering if it is possible to actually do this without explicitly grabbing each register we want because of how the translator works (which is assume what the comment is referring to). That is that in the actual translator we dont have a register state manifested. This might just be down to me not knowing about some helper that exists in the generator for generating a full register state

[sauclovian-g]

This is for modeling making system calls, not executing system call handlers, right? I would (based on knowing a lot more than I want to about syscall ABIs on a lot of targets) definitely recommend manifesting a complete register state and letting environment-specific syscall logic operate on it. There's a strong tendency to run into special-case calls that do magic things, especially on non-mainstream OSes, not to mention certain traditional mainstream special-case things like returning two values at once.

[RyanGlScott]

This is for making system calls, yes.

[sauclovian-g]

For example, a hack I've seen (no idea how likely one is to see it in the wild) for implementing fork is to have the syscall stub push all the callee-save registers before issuing the syscall, then pop them again. Then the parent process returns normally, but the new child process starts by teleporting to the same PC with all its registers set to HAVOC... which is diametrically opposed to the behavior of normal syscalls. Anything that thinks it can reimplement its own system call stubs, like say the rust stdlib, will be wrong if it doesn't take account of this behavior, so the syscall modeling also needs to.

[langston-barrett]

I also agree that these constructors should be OS/ABI agnostic.

What if we just pass the full register state to ARMSyscall and friends?

This also feels like the most natural solution to me. The straightforward way to implement it would be to capture an Assignment over a Ctx of all the register types. There are two problems here:

(1) Macaw CFG statements are required to have explicit return types, so we'd need a type family to turn this Ctx into a TupleType:

macaw/x86/src/Data/Macaw/X86/ArchTypes.hs

Line 817 in 54af25d

-> X86PrimFn f (TupleType [BVType w, BVType w])

(2) The type family that defines this Ctx lives in macaw-symbolic, and its instances live in macaw-*-symbolic:

macaw/symbolic/src/Data/Macaw/Symbolic/PersistentState.hs

Line 212 in 54af25d

type family ArchRegContext (arch :: K.Type) :: Ctx M.Type

Regarding (2), there's no reason that we couldn't define type synonyms for those Ctxs in macaw-* and leave the instances in macaw-*-symbolic.

[langston-barrett]

Whoops, hit the wrong button.