• Locked Locked
  • Replies 10 replies
  • Subscribers 119 subscribers
  • Views 7470 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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?

AlexRast
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
  • Note: This was originally posted on 18th September 2009 at http://forums.arm.com

    Given the information you have provided, the compiler doesn't appear to have done anything illegal.

    s.


    is this because of this comment?

    "Registers r0 to r3 and r12 may be corrupted between in function calls, so the compiler is fine to do this. The function must, however, ensure that r4 to r11 and sp are preserved. See page 15 of the ARM Procedure Call Standard.

    But if that's the case, why is the compiler stacking registers r2 and r3 in the first place? If these can be corrupted arbitrarily then it is a complete waste of time to stack them under essentially any situation.

    I have problems with the way the ARM procedure call standard is written, because it seems in a lot of cases to be very ambiguous in its choice of language. For instance, for registers what they state is this:

    "The first four registers r0-r3 (a1-a4) are used to pass argument values into a subroutine and to return a result value from a function. They may also be used to hold intermediate values within a routine (but, in general, only between subroutine calls).
    Register r12 (IP) may be used by a linker as a scratch register between a routine and any subroutine it calls (for details, see §5.3.1.1, Use of IP by the linker). It can also be used within a routine to hold intermediate values between subroutine calls.
    The role of register r9 is platform specific. A virtual platform may assign any role to this register and must document this usage. For example, it may designate it as the static base (SB) in a position-independent data model, or it may designate it as the thread register (TR) in an environment with thread-local storage. The usage of this register may require that the value held is persistent across all calls. A virtual platform that has no need for such a special register may designate r9 as an additional callee-saved variable register, v6.
    Typically, the registers r4-r8, r10 and r11 (v1-v5, v7 and v8) are used to hold the values of a routine's local variables. Of these, only v1-v4 can be used uniformly by the whole Thumb instruction set, but the AAPCS does not require that Thumb code only use those registers.
    A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."

    There are several parts of this that I find confusing. "...hold intermediate values within a routine (but in general only between subroutine calls)". As that statement is worded what I would think that would mean is: registers r0-r3 may be used in a routine, such that that routine calls subroutines, so that the values held within those registers map directly into variables in the lower-level subroutine. In other words, if you have int foo(int x, int y, int z) and int bar(int a, int b), if the intention is that values x and y from foo are to be used directly in bar as a and b, it's OK for the ATPCS to keep the values in r0 and r1, then simply branch into bar with those values intact. The value bar returned in r0 could then form the return value from foo as well, simply by keeping r0 in foo until it returns. This would seem to me at least reasonably sensible - i.e. no need to shuffle registers around if you're going to pass them right into a subroutine anyway. That, however, is clearly not the sense in which ARM actually uses these registers and I wish they would use more explicit language to describe exactly what is, and is not, allowed.

    If the statement above, "Registers r0 to r3 and r12 may be corrupted..." is correct, would it be accurate then to describe the situation as:

    Registers r0-r3 and r12 may be used within a routine only to the extent that the programmer can guarantee no branch or exception from within the routine can result in a context switch that would require these registers to have the same value upon return from the branch that they had before the branch.

    If this statement is correct then I'm happy to accept that the compiler is doing nothing likely to break higher-level functions, although that still begs the question of why in that case it would bother to stack r2 and r3 anyway - especially r2 since it could know that the stacked value would be corrupted later. Meanwhile, if this summarises the position, why doesn't the ATPCS/AAPCS use a statement with similar such language that makes it explicitly clear what it's going to do in local situations?
Reply
  • Note: This was originally posted on 18th September 2009 at http://forums.arm.com

    Given the information you have provided, the compiler doesn't appear to have done anything illegal.

    s.


    is this because of this comment?

    "Registers r0 to r3 and r12 may be corrupted between in function calls, so the compiler is fine to do this. The function must, however, ensure that r4 to r11 and sp are preserved. See page 15 of the ARM Procedure Call Standard.

    But if that's the case, why is the compiler stacking registers r2 and r3 in the first place? If these can be corrupted arbitrarily then it is a complete waste of time to stack them under essentially any situation.

    I have problems with the way the ARM procedure call standard is written, because it seems in a lot of cases to be very ambiguous in its choice of language. For instance, for registers what they state is this:

    "The first four registers r0-r3 (a1-a4) are used to pass argument values into a subroutine and to return a result value from a function. They may also be used to hold intermediate values within a routine (but, in general, only between subroutine calls).
    Register r12 (IP) may be used by a linker as a scratch register between a routine and any subroutine it calls (for details, see §5.3.1.1, Use of IP by the linker). It can also be used within a routine to hold intermediate values between subroutine calls.
    The role of register r9 is platform specific. A virtual platform may assign any role to this register and must document this usage. For example, it may designate it as the static base (SB) in a position-independent data model, or it may designate it as the thread register (TR) in an environment with thread-local storage. The usage of this register may require that the value held is persistent across all calls. A virtual platform that has no need for such a special register may designate r9 as an additional callee-saved variable register, v6.
    Typically, the registers r4-r8, r10 and r11 (v1-v5, v7 and v8) are used to hold the values of a routine's local variables. Of these, only v1-v4 can be used uniformly by the whole Thumb instruction set, but the AAPCS does not require that Thumb code only use those registers.
    A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."

    There are several parts of this that I find confusing. "...hold intermediate values within a routine (but in general only between subroutine calls)". As that statement is worded what I would think that would mean is: registers r0-r3 may be used in a routine, such that that routine calls subroutines, so that the values held within those registers map directly into variables in the lower-level subroutine. In other words, if you have int foo(int x, int y, int z) and int bar(int a, int b), if the intention is that values x and y from foo are to be used directly in bar as a and b, it's OK for the ATPCS to keep the values in r0 and r1, then simply branch into bar with those values intact. The value bar returned in r0 could then form the return value from foo as well, simply by keeping r0 in foo until it returns. This would seem to me at least reasonably sensible - i.e. no need to shuffle registers around if you're going to pass them right into a subroutine anyway. That, however, is clearly not the sense in which ARM actually uses these registers and I wish they would use more explicit language to describe exactly what is, and is not, allowed.

    If the statement above, "Registers r0 to r3 and r12 may be corrupted..." is correct, would it be accurate then to describe the situation as:

    Registers r0-r3 and r12 may be used within a routine only to the extent that the programmer can guarantee no branch or exception from within the routine can result in a context switch that would require these registers to have the same value upon return from the branch that they had before the branch.

    If this statement is correct then I'm happy to accept that the compiler is doing nothing likely to break higher-level functions, although that still begs the question of why in that case it would bother to stack r2 and r3 anyway - especially r2 since it could know that the stacked value would be corrupted later. Meanwhile, if this summarises the position, why doesn't the ATPCS/AAPCS use a statement with similar such language that makes it explicitly clear what it's going to do in local situations?
Children
No data