[Bug target/60109] New: __builtin_frame_address does not work as documented on ARM

[Bug target/60109] New: __builtin_frame_address does not work as documented on ARM

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109

            Bug ID: 60109
           Summary: __builtin_frame_address does not work as documented on
                    ARM
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

__builtin_frame_address does not work as documented on ARM. For a value
greater or equal to 1 it returns a non null value but the returned
pointer does not seem to match a frame. See the attached testcase. With
tcc and clang it displays "__builtin_frame_address" while with gcc it
first displays "bfa1: %s" and then segfaults if the #if is removed.


amd64:
$ gcc builtin_frame_address.c && ./a.out
str: __builtin_frame_address
bfa1: __builtin_frame_address

armhf:
str: __builtin_frame_address
bfa1:  %s

$ cat builtin_frame_address.c 
#include <stdio.h>
#include <stddef.h>

void bfa3(ptrdiff_t str_offset)
{
    printf("bfa3: %s\n", (char *)__builtin_frame_address(3) + str_offset);
}
void bfa2(ptrdiff_t str_offset)
{
    printf("bfa2: %s\n", (char *)__builtin_frame_address(2) + str_offset);
    bfa3(str_offset);
}
void bfa1(ptrdiff_t str_offset)
{
    printf("bfa1: %s\n", (char *)__builtin_frame_address(1) + str_offset);
#if defined(__arm__) && !defined(__GNUC__)
    bfa2(str_offset);
#endif
}

void builtin_frame_address_test(void)
{
    char str[] = "__builtin_frame_address";
    char *fp0 = __builtin_frame_address(0);

    printf("str: %s\n", str);
    bfa1(str-fp0);
}

int main(void)
{
    builtin_frame_address_test();
    return 0;
}

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
This is an unresolvable problem.

If we made __builtin_frame_address(N > 0) always return 0, then some useful use
cases for debugging would be excluded.

On the other hand, it is impossible to know whether it will return a useful
value in other cases, since it is dependent on all code being:
a) built with the same instruction set (arm or thumb)
b) Having a consistent use of the frame pointer.

My inclination is to resolve this as "won't fix".

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Agreed, this is effectively requesting for a frame pointer mandatorily in the
ABI.


regards
Ramana

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
WONTFIX as there have been no further comments and based on the last 2
comments.

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[thomas.preudhomme at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109

--- Comment #4 from Thomas Preud'homme <thomas.preudhomme at arm dot com> ---
Sorry for the late reply, I wasn't aware of this bug report until today.

(In reply to Richard Earnshaw from comment #1)
> This is an unresolvable problem.
> 
> If we made __builtin_frame_address(N > 0) always return 0, then some useful
> use cases for debugging would be excluded.
> 
> On the other hand, it is impossible to know whether it will return a useful
> value in other cases, since it is dependent on all code being:
> a) built with the same instruction set (arm or thumb)

Doesn't gcc use the same instruction set for a given compilation unit? I
thought an application (without its libraries) would typically not mix
instruction sets and therefore builtin_(return|frame)_address could be made to
work within an application in 99% of the cases even if it breaks accross
library calls (that could be compiled with different instruction set).

> b) Having a consistent use of the frame pointer.

It was my understanding that having a __builtin_frame_address disable frame
pointer elimination base of the following comment in expand_builtin_return_addr
():

"For a nonzero count, or a zero count with __builtin_frame_address, we require
a stable offset from the current frame pointer to the previous one, so we must
use the hard frame pointer, and we must disable frame pointer elimination."

The fact that other compilation unit might not have a frame pointer because
they were compiled with different compilers is ok. It would be nice that it
works within a given compilation unit (as in the example in the initial email)
though.