On 11/07/18 16:12, Denis Khalikov wrote:
> Hello everyone,
> I have a question about frame pointer for the thumb mode.
>
> This is my example:
>
> $cat a.cc
> __attribute__((noinline)) int bar(int a) { return a + 1; }
> __attribute__((noinline)) int foo(int a) { return bar(a + 1); }
> int main(int argc, char **argv) { return foo(argc); }
>
> $armv7l-linux-gnueabi-g++ --version
> armv7l-linux-gnueabi-g++ (GCC) 9.0.0 20180709 (experimental)
>
> $armv7l-linux-gnueabi-g++ -o a.S a.cc -fno-omit-frame-pointer -S -marm
>
> The prologue for the foo () function is:
>
> push {fp, lr}
> add fp, sp, #4
> sub sp, sp, #8
>
> Current fp points to lr on the stack, so it's easy to find previous fp
> on the stack.
>
> But, if we look at the same function with thumb mode, we will see the
> difference:
>
> $armv7l-linux-gnueabi-g++ -o a.S a.cc -fno-omit-frame-pointer -S -mthumb
>
> push {r7, lr}
> sub sp, sp, #8
> add r7, sp, #0
>
> In this case the frame pointer points to the top of the stack (in case
> stack grows downward) or whatever thumb_set_frame_pointer() function
> will emit. So, looks like it's impossible to find the previous frame
> pointer at the runtime, because we should know the amount of the local
> vars and the size of them, in my example.
>
> Also, as far as I understood, clang produce code with frame pointer
> which points to the predictable location for the arm and thumb modes.
>
> $clang++ -o a.S a.cc -fno-omit-frame-pointer -mthumb -S -target armv7l
>
> push {r7, lr}
> mov r7, sp
> sub sp, #8
>
> $clang++ -o a.S a.cc -fno-omit-frame-pointer -marm -S -target armv7l
>
> push {r11, lr}
> mov r11, sp
> sub sp, sp, #8
>
> So, my question is, does GCC has any restrictions about frame layout
> generation for the thumb mode or it could be rewrited ?
> Thanks.
>
The AAPCS does not define a frame pointer, so any code that uses one may
implement it in any way that it sees fit. It can only be used
internally within that function.
R.
