This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Compiler creates a bug in code - how to fix?

Note: This was originally posted on 17th September 2009 at http://forums.arm.com

I wouldn't have thought ARMCC could create an explicit bug, but it seems here it is.

In this case, what it's doing is placing an item on the stack in a position which will certainly corrupt the stack.

Looking through the disassembly for the offending function, I can see that the first line (as expected) is

PUSH     {r2-r4,r6-r11,lr}

But then later in the code, and with NO other stack operations in the meanwhile (nor any function calls or other branches out of the current function context) it has

ADD      r2,r0,r4,LSL #2
LDR      r0,|L1.3728|
STR      r2,[sp,#4]

As I understand it, since the stack is full-descending, this means that the value of r2 currently in the stack will get corrupted, because the STR instruction will store the (changed) current r2 value in the position occupied by the original r2. The function in concern is declared

void receivePacket(void)

so it's not expecting to return values in r2 or take arguments in r2.

Why would armcc do something so glaringly illegal? Is there something I can do to fix this?

As an aside, I'll mention that this bad stacking is actually occuring in the setup for a subroutine call, that happens a few lines lower down. The routine in concern uses r1, r2 and r3 for its arguments and returns in r0 and r1. As it happens, the value that it's stacking from r2 is actually the address that will take the return value in r0 - really, what the compiler *should* do, I think, is place the address in some register rx (x > 3) then do an STR r0, [rx, #0] on return.

Parents

AlexRast over 12 years ago

Note: This was originally posted on 21st September 2009 at http://forums.arm.com

Yep, that's entirely sensible, and precisely what APCS lets you do.

What is means by "only in between subroutine calls" is that as soon as you call a subroutine that subroutine is free to clobber r0-r3 and r12 (in accordance with the APCS).

That's what I was expecting - since we know that r0-r3 are used for function parameters it would be natural to assume a function (subroutine) passed those parameters is (at least potentially) going to modify them - why else would you have given them to the function as parameters?

As written the spec leaves a bit of an ambiguity that I wasn't sure about before trying some things - namely if you have a function that doesn't have as many parameters as the number of registers set aside for possible parameter use, e.g. int foo(int x, int y), whether the compiler then interprets the "missing" registers as ones that need to be preserved, and whether the compiler allocates argument registers completely sequentially. For instance it could assign foo's arguments as: return in r0, x = r1, y = r2. Meanwhile what would it do with r3? I was able to discover right away that it will actually assign arguments as: return in r0, x = r0, y = r2. Now I think you've clarified that it will NOT necessarily stack r3 - thus any higher-level function must not have active values in r3 that must not be corrupted by foo.

If I've got this understood correctly this also means that if you want a function that returns a modified value of its arguments: e.g. int foo(int x, int y) {x = x + y; return x} then you can make the compiler's job easier by adept ordering of your parameter list.

So if the caller has stored any intermediate value in any of these clobberable registers, and it wants to use the value after the subroutine it either has to move the value in to r4-r11 or r13-14 or write it to the stack. So you cannot store intermediates "across subroutine calls" in the parameter passing or IP register ... otherwise you risk loosing the value.

My feeling is that this should have been more clearly spelled out in the spec. Actually, the words "between subroutine calls" and "across subroutine calls" are themselves ambiguous, I think, and either they should use more explicit language or define at the beginning of the spec exactly what these terms mean in their case.

In any case, thanks for the good explanation.

Most modern compilers operate on a "move the stack pointer once per function" (ignoring stack push and pop wrapping subroutines), so will essentially reserve enough space on the stack to ensure that any intermediate space on the stack for storing scratch values is allocated on function entry and freed on function exit. In your case, as you pointed out in your first post, the compiler stores r2 back to the stack as a scratch variable; the initial "push" of r2 and r3 is just to reserve the space without needing a second instruction to increment SP.

Interesting and a bit surprising. What's the theory behind doing that? My feeling would be that for efficiency's sake there's no sense messing about with the stack unless you're actually achieving something *necessary*. In ARM's case in particular, since the instruction set provides address preincrement/postincrement with any memory function anyway, placing an additional stack push wastes a machine cycle that you didn't need to do - because the ARM must do the intial pop at the beginning of the function and then must still actually store the value it wants to at the time it stacks the value.

If, on the other hand, the idea of this is to treat the stack as some sort of extension of the register space, so that each extended word corresponds to a fixed "stack" position, it isn't a stack anymore - at which point why not just read and write from heap or any other free memory area?

The APCS also requires the stack to be 8 byte aligned on function call, so r3 is probably pushed just to ensure an even number of registers are pushed, although your function may use that space for scratch stack too...

Ah, right, that's a possibility.

Thanks once again for the enlightening explanations.
Cancel
Vote up 0 Vote down

Cancel

Reply

AlexRast over 12 years ago

Note: This was originally posted on 21st September 2009 at http://forums.arm.com

Yep, that's entirely sensible, and precisely what APCS lets you do.

What is means by "only in between subroutine calls" is that as soon as you call a subroutine that subroutine is free to clobber r0-r3 and r12 (in accordance with the APCS).

That's what I was expecting - since we know that r0-r3 are used for function parameters it would be natural to assume a function (subroutine) passed those parameters is (at least potentially) going to modify them - why else would you have given them to the function as parameters?

As written the spec leaves a bit of an ambiguity that I wasn't sure about before trying some things - namely if you have a function that doesn't have as many parameters as the number of registers set aside for possible parameter use, e.g. int foo(int x, int y), whether the compiler then interprets the "missing" registers as ones that need to be preserved, and whether the compiler allocates argument registers completely sequentially. For instance it could assign foo's arguments as: return in r0, x = r1, y = r2. Meanwhile what would it do with r3? I was able to discover right away that it will actually assign arguments as: return in r0, x = r0, y = r2. Now I think you've clarified that it will NOT necessarily stack r3 - thus any higher-level function must not have active values in r3 that must not be corrupted by foo.

If I've got this understood correctly this also means that if you want a function that returns a modified value of its arguments: e.g. int foo(int x, int y) {x = x + y; return x} then you can make the compiler's job easier by adept ordering of your parameter list.

So if the caller has stored any intermediate value in any of these clobberable registers, and it wants to use the value after the subroutine it either has to move the value in to r4-r11 or r13-14 or write it to the stack. So you cannot store intermediates "across subroutine calls" in the parameter passing or IP register ... otherwise you risk loosing the value.

My feeling is that this should have been more clearly spelled out in the spec. Actually, the words "between subroutine calls" and "across subroutine calls" are themselves ambiguous, I think, and either they should use more explicit language or define at the beginning of the spec exactly what these terms mean in their case.

In any case, thanks for the good explanation.

Most modern compilers operate on a "move the stack pointer once per function" (ignoring stack push and pop wrapping subroutines), so will essentially reserve enough space on the stack to ensure that any intermediate space on the stack for storing scratch values is allocated on function entry and freed on function exit. In your case, as you pointed out in your first post, the compiler stores r2 back to the stack as a scratch variable; the initial "push" of r2 and r3 is just to reserve the space without needing a second instruction to increment SP.

Interesting and a bit surprising. What's the theory behind doing that? My feeling would be that for efficiency's sake there's no sense messing about with the stack unless you're actually achieving something *necessary*. In ARM's case in particular, since the instruction set provides address preincrement/postincrement with any memory function anyway, placing an additional stack push wastes a machine cycle that you didn't need to do - because the ARM must do the intial pop at the beginning of the function and then must still actually store the value it wants to at the time it stacks the value.

If, on the other hand, the idea of this is to treat the stack as some sort of extension of the register space, so that each extended word corresponds to a fixed "stack" position, it isn't a stack anymore - at which point why not just read and write from heap or any other free memory area?

The APCS also requires the stack to be 8 byte aligned on function call, so r3 is probably pushed just to ensure an even number of registers are pushed, although your function may use that space for scratch stack too...

Ah, right, that's a possibility.

Thanks once again for the enlightening explanations.
Cancel
Vote up 0 Vote down

Cancel

Children

No data