Reproducible with various compilers: gcc-6.4.0, hcc-7.2.0, gcc-master

How to reproduce:
- build glibc on powerpc-unknown-linux-gnu as:
  ../glibc/configure --prefix=/usr --enable-stack-protector=all
- run dynamic loader as:
  $ gdb --quiet --args elf/ld.so --library-path . /bin/ls
Reading symbols from elf/ld.so...done.
(gdb) run
Starting program: /root/glibc-build/elf/ld.so --library-path . /bin/ls

Program received signal SIGSEGV, Segmentation fault.
0x0fed1df8 in __GI___libc_malloc (bytes=5) at malloc.c:3062
3062        return (*hook)(bytes, RETURN_ADDRESS (0));
(gdb) list
3057      void *victim;
3058
3059      void *(*hook) (size_t, const void *)
3060        = atomic_forced_read (__malloc_hook);
3061      if (__builtin_expect (hook != NULL, 0))
3062        return (*hook)(bytes, RETURN_ADDRESS (0));
3063    #if USE_TCACHE
3064      /* int_free also calls request2size, be careful to not pad twice.  */
3065      size_t tbytes = request2size (bytes);
3066      size_t tc_idx = csize2tidx (tbytes);

It's caused by a gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81996
where -fstack-protector-all makes compiler to read return address from
invalid stack.

I've filed a glibc bug for two reasons:

1. Would be nice if glibc would have a workaround of not generating
  broken glibc on powerpc. I suggest adding '#define RETURN_ADDRESS(x) NULL'
  or reading 'lr' register directly.
2. Would be nice if glibc did not use __builtin_return_address at all.
  https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html suggests it's
  a debugging mechanism: """
  Calling this function with a nonzero argument can have unpredictable effects, including crashing the calling program. As a result, calls that are considered unsafe are diagnosed when the -Wframe-address option is in effect. Such calls should only be made in debugging situations. """

  Even though RETURN_ADDRESS(0) is supposed to work practice shows it does not.


glibc fails on RETURN_ADDRESS(0) by trying to fetch 'lr' from stack:
   ... <something in __libc_malloc>...
   0x0fed1df4 <+580>:   lwz     r10,32(r1)
=> 0x0fed1df8 <+584>:   lwz     r4,4(r10)

Thank you!