Re: [PATCH] powerpc: Remove backtrace implementation

[Paul E Murphy <murphyp@linux.ibm.com>]

On 2/26/21 11:39 AM, Raoni Fassina Firmino via Libc-alpha wrote:
> On Tue, Feb 23, 2021 at 09:43:28AM -0300, AL glibc-alpha wrote:
>>
>>
>> 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.
> 
> Is there any formal expectation of the environment in which bactrace()
> will work?  The manual don't seems to put too many constraints a part
> from having a well formatted stack.
> 
> Should it then be added that CFI information is necessary?

Ping?  This seems like a beneficial change.  Using the unwind
information makes for a much more robust backtrace with other languages
which support C bindings but do not use the same ABI (specifically
calling to and from go code in C).

Should we instead turn the existing ppc backtrace into a compat symbol?
This seems like it would address Tulio's issue with older binaries.