AMD64 Register dumper is used on ARM platforms.

[kirillp]

Currently, on Darwin systems only AMD64 register dumper is used, even on ARM (Platform.IOS_AARCH64):

@Platforms({Platform.DARWIN.class})
@AutomaticFeature
class DarwinUContextRegisterDumperFeature implements Feature {

This defect lead to weird behaviour like request for AMD64 registers in .cap files during IOS_AARCH64 build:

NativeCodeInfo:PosixDirectives:StructInfo:struct___darwin_mcontext64:StructFieldInfo:__ss___rax:PropertyInfo:size=8

All versions of GraalVM affected.

[kirillp]

suggested fix: Montura@f04db55

[teshull]

The suggested fix doesn't really fix the issue; the methods should be populated correctly.

[kirillp]

It prevents from invalid memory access. We can file a new issues to improve ARMRegisterDumper.

[kirillp]

This fix works for iOS development and production.
We have very clear and readable crash reports on console.firebase.google.com for production application.
As well as clear stack-traces during product debug and testing.

I agree that ARMRegisterDumper need more work to be better, but it can be done later and it minor.

[Montura]

@teshull, hi!

What about this fix Montura@d2f5b59. Is it enough?

Or I have to "fill" MContextArm64 with all the fields from _STRUCT_MCONTEXT64

https://github.com/xybp888/iOS-SDKs/blob/master/iPhoneOS11.2.sdk/usr/include/arm/_mcontext.h#L61

#define _STRUCT_MCONTEXT64	struct __darwin_mcontext64
{
	_STRUCT_ARM_EXCEPTION_STATE64	__es;
	_STRUCT_ARM_THREAD_STATE64	__ss;
	_STRUCT_ARM_NEON_STATE64	__ns;
};

https://github.com/xybp888/iOS-SDKs/blob/master/iPhoneOS11.2.sdk/usr/include/mach/arm/_structs.h#L96

#define _STRUCT_ARM_THREAD_STATE64	struct __darwin_arm_thread_state64
_STRUCT_ARM_THREAD_STATE64
{
	__uint64_t    __x[29];	/* General purpose registers x0-x28 */
	__uint64_t    __fp;		/* Frame pointer x29 */
	__uint64_t    __lr;		/* Link register x30 */
	__uint64_t    __sp;		/* Stack pointer x31 */
	__uint64_t    __pc;		/* Program counter */
	__uint32_t    __cpsr;	/* Current program status register */
	__uint32_t    __pad;    /* Same size for 32-bit or 64-bit clients */
};

Anyway I can't fill this methods properly, because I don't know in which general-purpose registers (x[29]) do you save HeapBase and Thread pointers.

class DarwinArmUContextRegisterDumper implements UContextRegisterDumper {
    @Override
    @Uninterruptible(reason = "Called from uninterruptible code", mayBeInlined = true)
    public PointerBase getHeapBase(ucontext_t uContext) {
        Signal.MContext64Arm sigcontext = uContext.uc_mcontext64_arm();
        return WordFactory.nullPointer();
    }

    @Override
    @Uninterruptible(reason = "Called from uninterruptible code", mayBeInlined = true)
    public PointerBase getThreadPointer(ucontext_t uContext) {
        Signal.MContext64Arm sigcontext = uContext.uc_mcontext64_arm();
        return WordFactory.nullPointer();
    }
}

[teshull]

Hi @Montura Thanks for the reference to the aarch64 structs. I started to look at this as well earlier today. I should merge a solution into master in the next week or so.

For future reference, on AArch64 the thread pointer is r28 and heap base pointer is 27. This information can be found in com.oracle.svm.core.graal.aarch64.AArch64ReservedRegisters

[teshull]

@Montura @kirillp Can you check if #3859 fixes your issue?

[Montura]

@teshull, I'll check it tomorrow.

[kirillp]

@teshull the patch looks good. Nice that you did all the remaining renames.
As I can see we are loosing one register on iOS, interesting will it affect performance much.
74b024e

[kirillp]

  features->fFP = !!(cpu_has("hw.optional.floatingpoint"));
  features->fASIMD = !!(cpu_has("hw.optional.neon"));

do we need to check it ?
AFIAK all Apple ARM 64 bit processors support FP and ASIMD from the 1st version.

[teshull]

I like to keep this code the same as in HotSpot; it doesn't hurt to keep it in

[kirillp]

can we see this in 21.3 ?

[teshull]

No, unfortunately it is too late for that. #3859 will be part of 22.0

[kirillp]

This is not good, we have to use own build again in CI. We could do my fix for 21.3 and yours for 22

[teshull]

The freeze for 21.3 was ~ a month ago, so it's too late to put any new things into it. If you don't want to build yourself, I imagine soon a nightly for 22.0 should be available here: https://github.com/graalvm/graalvm-ce-dev-builds/releases

[kirillp]

@Montura @kirillp Can you check if #3859 fixes your issue?

@teshull
Hello, I found a new issue: #4162