Skip to content

Conversation

@Araneidae
Copy link
Collaborator

This is all arising from issue #68 and PR #76. It seems that MacOS Arm64 does not like the use of relocation in the original switch-arm64.c code. This arises from a single instruction
ldr lr, =action_entry

As action_entry is extremely close to this code this can simply be replaced with
adr lr, action_entry
for both ARM32 and ARM64.

Apologies to @graeme-winter, this obsoletes your PR #76. Unfortunately I have no way to test this. Perhaps you can test this, at least for ARM64?

@graeme-winter
Copy link
Contributor

@Araneidae I filter the DiamondLightSource notifications so did not see you had closed my original PR nor the request above, just saw when checking in on this

I note that your code does not build

<inline asm>:33:8: error: unknown AArch64 fixup kind!
   33 |        adr lr, action_entry
      |        ^
1 error generated.

I note that the recommendation is to use the changes I had proposed in #76

I suspect you cannot avoid a conditional

@graeme-winter
Copy link
Contributor

Alternatively, you could simply reopen #76 as this is likely the conceptually minimal change-set to address the fundamental issue?

This is all arising from issue #68 and PR #76.  It seems that MacOS Arm64
does not like the use of relocation in the original switch-arm64.c code.
This arises from a single instruction
    ldr lr, =action_entry

As action_entry is extremely close to this code this can simply be replaced
with
    adr lr, action_entry
for both ARM32 and ARM64.
@Araneidae
Copy link
Collaborator Author

That is interesting and rather annoying.

I've done a bit of research, but unfortunately @graeme-winter I'm relying on you to run the tests as I don't actually have access to an OSX AArch64 compiler. The compiler appears to be complaining that it can't compute the relocation for adr, which is especially annoying because it doesn't need to: this is now perfectly good position independent code!

I've also seen a hint that the OSX assembler doesn't actually look forwards when assembling this instruction, which suggests that using an explicit forward reference might work, so I've tried that.

Let me know if this works any better.

@graeme-winter
Copy link
Contributor

That is interesting and rather annoying.

I've done a bit of research, but unfortunately @graeme-winter I'm relying on you to run the tests as I don't actually have access to an OSX AArch64 compiler. The compiler appears to be complaining that it can't compute the relocation for adr, which is especially annoying because it doesn't need to: this is now perfectly good position independent code!

I've also seen a hint that the OSX assembler doesn't actually look forwards when assembling this instruction, which suggests that using an explicit forward reference might work, so I've tried that.

Let me know if this works any better.

It would appear not:

<inline asm>:33:8: error: unknown AArch64 fixup kind!
   33 |        adr lr, .1f
      |        ^
1 error generated.
error: command '/usr/bin/clang' failed with exit code 1

@Araneidae
Copy link
Collaborator Author

Sigh.

Ok, I give up, I'll reinstate your branch and merge it.

My frustration is that adr generates position independent code when used to reference a label in the same text segment ... and it looks as if the OSX compiler is simply refusing to recognise this. The target is only 12 instructions away! I do wonder if nonsense like adr lr, .+24 would work (there's no way I would merge that, though).

@Araneidae Araneidae closed this Oct 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants