Re: [PATCH] powerpc: Remove backtrace implementation

[Raoni Fassina Firmino <raoni@linux.ibm.com>]

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?

> 
> 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).