Skip to content

Dealing with Windows CE ABI (OABI)/heap allocation incompatibilities #2

Description

@dogtopus

Turns out that Windows CE ARM calling convention is not AAPCS-compatible and more close to the old APCS, specifically the stack alignment is 4 bytes instead of 8. This could cause a problem when passing 64-bit values. Moreover, the Besta heap allocator allocates the memory aligned to 4 bytes as well. This may break dynamically allocated structs that use int64/double values since AAPCS explicitly stated that they should be aligned to the biggest data type present in the struct i.e. 8 bytes.

So far none of the syscall routines documented seems to be affected by this problem, but in case it happens, do the following:

  • For syscalls that use the Windows CE CC/APCS in the incompatible way, use a thunk defined in muteki-shims to make them EABI-and-AAPCS-compatible. (May need to add an src folder to handle this as well as renaming the raw shims to something else)
  • For structs allocated by the kernel and can potentially have unaligned 64 bit values, set the field alignment of 64-bit values to 4 and use packed layout (i.e. __attribute__((packed, aligned(4))). This is defined in muteki-shims as SYS_DWORD)

Downgrading to OABI might also be an optional solution but that might also bring more problems to the table (compiler features specific to EABI might be missing/broken) so use with caution. This should be supportable by extending the platform check macro to also check for OABI/EABI in addition to MSVC.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions