Live data from Hacker News

ARM Assembly: ∞ Ways to Return (2017)

quantum5.ca

1–10 of 23 posts

Re: ARM Assembly: ∞ Ways to Return (2017)

#3

fwiw, if you're using ARM assembly on an Apple device there are a few differences and one of them is how you pass arguments. https://developer.apple.com/documentation/xcode/writing-arm6...

The article is describing classic ARM. (Modern) Apple devices are all ARM64, which doesn't have the PC as a GPR.

The article is also entirely about how the PC is a general-purpose register on 32-bit ARM machines. No idea if the 1st gen iPhones or whatever used an idiosyncratic calling convention...but it's moot in the context of this post, because argument passing isn't covered here!

This post really is just about the observation that the PC is a GPR implies that there's a bunch of different ways to get data into it. It's pretty airy. The author was admittedly a first or second year university student at the time, so it's hard to be too mad though.

Re: ARM Assembly: ∞ Ways to Return (2017)

#4
Thankfully, PC is no longer a GPR in ARM64. Making PC a GPR seems elegant at first glance, but when you actually dive into it and see how it affects processor implementations and how it affects the code you write, it turns out to be extremely messy and inconvenient. Good riddance PC as GPR, don’t let the door hit you on the way out.

Re: ARM Assembly: ∞ Ways to Return (2017)

#5
Method 1 (popping PC off the stack) and Method 3 (mov pc,lr) do not work on the earliest ARM processors that support THUMB, as it will not switch to THUMB mode without executing a BX instruction.

Checking reference manuals:

ARMV4T (ARM7TDMI/ARM9TDMI): Does NOT switch to THUMB mode automatically

ARMV5: Does NOT switch to THUMB mode automatically

ARMV7: Does switch to THUMB mode automatically

Re: ARM Assembly: ∞ Ways to Return (2017)

#6
post #5

Method 1 (popping PC off the stack) and Method 3 (mov pc,lr) do not work on the earliest ARM processors that support THUMB, as it will not switch to THUMB mode without executing a BX instruction. Checking reference manuals: ARMV4T (ARM7TDMI/ARM9TDMI): Does NOT switch to THUMB mode automatically ARMV5: Does NOT switch to THUMB mode automatically ARMV7: Does switch to THUMB mode automatically

I thought it switched to thumb based on odd/ evenness.

Plus if you don't want to switch to thumb, this still works?

Re: ARM Assembly: ∞ Ways to Return (2017)

#7
post #6
post #5

Method 1 (popping PC off the stack) and Method 3 (mov pc,lr) do not work on the earliest ARM processors that support THUMB, as it will not switch to THUMB mode without executing a BX instruction. Checking reference manuals: ARMV4T (ARM7TDMI/ARM9TDMI): Does NOT switch to THUMB mode automatically ARMV5: Does NOT switch to THUMB mode automatically ARMV7: Does switch to THUMB mode automatically

I thought it switched to thumb based on odd/ evenness. Plus if you don't want to switch to thumb, this still works?

It does work if you intend to stay in ARM mode only, and will crash if THUMB-mode code calls the function. ARMV7 will do the mode switch automatically and not crash.

Re: ARM Assembly: ∞ Ways to Return (2017)

#8
Early versions of ARM (ARM 1/2, optional in 3/4) had a combined program counter / status register; since there was only a 26-bit address space and instructions are always 32-bit word aligned, the top 6 and bottom 2 bits were used for the status register.

So, if you're still developing for an ARM1, not all of these are equivalent. MOV/POP/etc will set the PC and the status register; B/BL will leave the status register bits alone.

* edit: MOV/MOVS determined if the status bits are written to R15.

Re: ARM Assembly: ∞ Ways to Return (2017)

#9
In 2010, I tried to use callgrind to profile a project on Arm, after having used it to great effect on x86, and discovered that because of the variety of ways to return (and call!) functions on Arm, callgrind was unable to reliably identify function call and return sites. It created cycles in the call graph and even failed to record a function's self measurements correctly (because it could not tell when you left that function).

The problem boiled down to the valgrind frontend code that splits things up into basic blocks being incapable of having an instruction be both a conditional jump and a function call / return at the same time. That never happens on x86, but of course this is possible (and totally normal) on 32-bit Arm. Sadly, I ran out of time to try to re-architect this code and had to move on to other projects.

Over 12 years later, it looks like it never did get fixed: https://bugs.kde.org/show_bug.cgi?id=252091

Re: ARM Assembly: ∞ Ways to Return (2017)

#10
post #9

In 2010, I tried to use callgrind to profile a project on Arm, after having used it to great effect on x86, and discovered that because of the variety of ways to return (and call!) functions on Arm, callgrind was unable to reliably identify function call and return sites. It created cycles in the call graph and even failed to record a function's self measurements correctly (because it could not tell when you left tha…

I use stuff like "bxeq lr" all the time. There's your conditional return instruction.
Post reply on HN