[PATCH] powerpc: Remove backtrace implementation

[Adhemerval Zanella]

On 23/02/2021 09:28, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> Afaik this is true for every other architecture that uses libgcc for
>> backtrace implementation, currently *everything* but powerpc and
>> microblaze:
>>
>> This is on aarch64 with gcc 5.4:
>>
>> $ gcc -g0 -fno-asynchronous-unwind-tables backtrace.c -o backtrace
>> $ ./backtrace 3
>> backtrace() returned 1 addresses
>> ./backtrace() [0x4009dc]
>>
>> And this is sparc64 with gcc-10:
>>
>> $ gcc -g0 -fno-asynchronous-unwind-tables backtrace.c -o backtrace
>> $ ./backtrace 3
>> backtrace() returned 1 addresses
>> ./backtrace(+0xa74) [0x10000000a74]
>>
>> So for all other architectures we require -fasynchronous-unwind-tables
>> to get backtrace work and I plan to remove microblaze implementation
>> so powerpc will be only outlier.
> 
> GCC's defaults matter as well, I think.  If GCC defaults to unwind
> tables (is -funwind-tables sufficient?), then the libgcc_s unwinder will
> work for default builds.

I think -funwind-tables is not suffice on some architectures to unwind
through signal handlers.

> 
> The libgcc_s unwinder may also have custom backchain logic for some
> targets, I haven't checked.

This a point to actually use libgcc instead of using custom implementations
on glibc.

> 
> Part of the challenge here is whether people consider unwind tables or
> frame pointers part of the ABI.  There doesn't seem to be consensus,
> even for Linux targets (I think people on the musl side dislike the
> tables).
My view is glibc should not need to handle it, my point is use what
compiler already provide as a unwinder solution so we don't need to
handle all possible ABI variations and extensions that compiler or
use might use.

The backtrace originally was just a slim wrapper over libgcc and
musl does not like because it does not provide bracktrace and it
is aiming to be a lightweight solution (and -f*unwind-tables does
generate a lot of additional information).