powerpc: Remove backtrace implementation
Commit Message
The powerpc optimization to provide a fast stacktrace requires some
ad-hoc code to handle Linux signal frames and the change is fragile
once the kernel decides to slight change its execution sequence [1].
The generic implementation work as-is and it should be future proof
since the kernel provides the expected CFI directives in vDSO shared
page.
Checked on powerpc-linux-gnu, powerpc64le-linux-gnu, and
powerpc64-linux-gnu.
[1] https://sourceware.org/pipermail/libc-alpha/2021-January/122027.html
---
sysdeps/powerpc/powerpc32/backtrace.c | 133 -----------------------
sysdeps/powerpc/powerpc64/backtrace.c | 117 --------------------
sysdeps/unix/sysv/linux/dl-vdso-setup.c | 11 --
sysdeps/unix/sysv/linux/dl-vdso-setup.h | 9 --
sysdeps/unix/sysv/linux/powerpc/sysdep.h | 7 --
5 files changed, 277 deletions(-)
delete mode 100644 sysdeps/powerpc/powerpc32/backtrace.c
delete mode 100644 sysdeps/powerpc/powerpc64/backtrace.c
Comments
* Adhemerval Zanella:
> The powerpc optimization to provide a fast stacktrace requires some
> ad-hoc code to handle Linux signal frames and the change is fragile
> once the kernel decides to slight change its execution sequence [1].
>
> The generic implementation work as-is and it should be future proof
> since the kernel provides the expected CFI directives in vDSO shared
> page.
>
> Checked on powerpc-linux-gnu, powerpc64le-linux-gnu, and
> powerpc64-linux-gnu.
>
> [1] https://sourceware.org/pipermail/libc-alpha/2021-January/122027.html
Does this really work well (enough) on systems which do not build
everything with asynchronous unwind tables? If I recall correctly, GCC
enabled them by default only quite recently.
Thanks,
Florian
On 12/02/2021 14:21, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> The powerpc optimization to provide a fast stacktrace requires some
>> ad-hoc code to handle Linux signal frames and the change is fragile
>> once the kernel decides to slight change its execution sequence [1].
>>
>> The generic implementation work as-is and it should be future proof
>> since the kernel provides the expected CFI directives in vDSO shared
>> page.
>>
>> Checked on powerpc-linux-gnu, powerpc64le-linux-gnu, and
>> powerpc64-linux-gnu.
>>
>> [1] https://sourceware.org/pipermail/libc-alpha/2021-January/122027.html
>
> Does this really work well (enough) on systems which do not build
> everything with asynchronous unwind tables? If I recall correctly, GCC
> enabled them by default only quite recently.
This should work as well any other architecture since it uses the libgcc_s
routines. Afaik the powerpc implementation was done as optimization, not
for correctness.
Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> On 12/02/2021 14:21, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>> Does this really work well (enough) on systems which do not build
>> everything with asynchronous unwind tables? If I recall correctly, GCC
>> enabled them by default only quite recently.
>
> This should work as well any other architecture since it uses the libgcc_s
> routines. Afaik the powerpc implementation was done as optimization, not
> for correctness.
I think Florian is correct.
GCC enabled -fasynchronous-unwind-tables by default on ppc* ELF targets on
version 8 [1].
So if you take a Debian 10 ppc64le, build the backtrace example from
linux-manpages [2] with gcc-7 or with a newer GCC using
'gcc-9 -g0 -fno-asynchronous-unwind-tables', this executable won't be able to
print the correct backtrace, e.g.:
$ ./testrun.sh ./tst-no-asynchronous-unwind-tables 3
backtrace() returned 1 addresses
./tst-no-asynchronous-unwind-tables(+0xb48) [0x7fff99a00b48]
8 addresses were expected in the previous test.
With that said, I don't think the powerpc files are just an optimization and
removing them may cause old binaries to stop getting the right backtrace.
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0359465c703a
[2] https://www.man7.org/linux/man-pages/man3/backtrace.3.html
* Tulio Magno Quites Machado Filho:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>
>> On 12/02/2021 14:21, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>> Does this really work well (enough) on systems which do not build
>>> everything with asynchronous unwind tables? If I recall correctly, GCC
>>> enabled them by default only quite recently.
>>
>> This should work as well any other architecture since it uses the libgcc_s
>> routines. Afaik the powerpc implementation was done as optimization, not
>> for correctness.
>
> I think Florian is correct.
>
> GCC enabled -fasynchronous-unwind-tables by default on ppc* ELF targets on
> version 8 [1].
> So if you take a Debian 10 ppc64le, build the backtrace example from
> linux-manpages [2] with gcc-7 or with a newer GCC using
> 'gcc-9 -g0 -fno-asynchronous-unwind-tables', this executable won't be able to
> print the correct backtrace, e.g.:
>
> $ ./testrun.sh ./tst-no-asynchronous-unwind-tables 3
> backtrace() returned 1 addresses
> ./tst-no-asynchronous-unwind-tables(+0xb48) [0x7fff99a00b48]
>
> 8 addresses were expected in the previous test.
>
> With that said, I don't think the powerpc files are just an optimization and
> removing them may cause old binaries to stop getting the right backtrace.
>
> [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0359465c703a
> [2] https://www.man7.org/linux/man-pages/man3/backtrace.3.html
Meh, I feel like I have an egg on my face. I was pretty sure yesterday
that the change was safe after all. Thanks for checking.
Is there are reason why the libgcc_s unwinder does not use the backchain
if no DWARF data is available?
Florian
On 22/02/2021 19:16, Tulio Magno Quites Machado Filho wrote:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>
>> On 12/02/2021 14:21, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>> Does this really work well (enough) on systems which do not build
>>> everything with asynchronous unwind tables? If I recall correctly, GCC
>>> enabled them by default only quite recently.
>>
>> This should work as well any other architecture since it uses the libgcc_s
>> routines. Afaik the powerpc implementation was done as optimization, not
>> for correctness.
>
> I think Florian is correct.
>
> GCC enabled -fasynchronous-unwind-tables by default on ppc* ELF targets on
> version 8 [1].
> So if you take a Debian 10 ppc64le, build the backtrace example from
> linux-manpages [2] with gcc-7 or with a newer GCC using
> 'gcc-9 -g0 -fno-asynchronous-unwind-tables', this executable won't be able to
> print the correct backtrace, e.g.:
>
> $ ./testrun.sh ./tst-no-asynchronous-unwind-tables 3
> backtrace() returned 1 addresses
> ./tst-no-asynchronous-unwind-tables(+0xb48) [0x7fff99a00b48]
>
> 8 addresses were expected in the previous test.
>
> With that said, I don't think the powerpc files are just an optimization and
> removing them may cause old binaries to stop getting the right backtrace.
>
> [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0359465c703a
> [2] https://www.man7.org/linux/man-pages/man3/backtrace.3.html
>
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.
The question is: should we fix all other architectures to provide a
non-libgcc way to get around this issue? What about architectures that
backtrace through frame layout is not really possible or require hackish
ways (-fomit-frame-pointer for some architecture or thumb mode with
gcc and clang objects)?
I really don't think we should keep this fast-unwinders (sanitizers
has a hard time maintaining for some architectures) so I still think
we should move to use *just* libgcc as backend and document the flags
required to get a meaningful stacktrace
* 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.
The libgcc_s unwinder may also have custom backchain logic for some
targets, I haven't checked.
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).
Thanks,
Florian
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).
On Fri, Feb 12, 2021 at 02:09:41PM -0300, Adhemerval Zanella wrote:
> The powerpc optimization to provide a fast stacktrace requires some
> ad-hoc code to handle Linux signal frames and the change is fragile
> once the kernel decides to slight change its execution sequence [1].
>
> The generic implementation work as-is and it should be future proof
> since the kernel provides the expected CFI directives in vDSO shared
> page.
>
> Checked on powerpc-linux-gnu, powerpc64le-linux-gnu, and
> powerpc64-linux-gnu.
>
FWIW I also checked on:
- powerpc-linux-gnu (with 64bits 5.10 kernel)
- powerpc64le-linux-gnu (with new 5.11 kernel)
- powerpc64-linux-gnu (with new 5.11 kernel)
With and without Florian's unwind patch series and it seems to be ok in
both cases.
o/
Raoni
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).
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.
Paul E Murphy via Libc-alpha <libc-alpha@sourceware.org> writes:
> 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.
If we do this, we'll never be able to remove the old implementation, which was
Adhemerval's goal.
I particularly agree that duplicated code should be removed and I believe it
would be helpful if libgcc had the fallback code.
On 15/04/2021 11:42, Tulio Magno Quites Machado Filho wrote:
> Paul E Murphy via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> 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.
>
> If we do this, we'll never be able to remove the old implementation, which was
> Adhemerval's goal.
> I particularly agree that duplicated code should be removed and I believe it
> would be helpful if libgcc had the fallback code.
>
As before, I don't think this is a ABI breaker and making powerpc align
with other architecture simplifies the code and align the expectation.
And afaik all projects that do require fast unwinder do it themselves
(libsanitizer for instance) instead.
* Adhemerval Zanella via Libc-alpha:
> On 15/04/2021 11:42, Tulio Magno Quites Machado Filho wrote:
>> Paul E Murphy via Libc-alpha <libc-alpha@sourceware.org> writes:
>>
>>> 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.
>>
>> If we do this, we'll never be able to remove the old implementation, which was
>> Adhemerval's goal.
>> I particularly agree that duplicated code should be removed and I believe it
>> would be helpful if libgcc had the fallback code.
>>
>
> As before, I don't think this is a ABI breaker and making powerpc
> align with other architecture simplifies the code and align the
> expectation.
>
> And afaik all projects that do require fast unwinder do it themselves
> (libsanitizer for instance) instead.
I criticized this change before, but I'm now neutral, or maybe even
slightly in favor. Please ignore what I said/wrote before.
Thanks,
Florian
On 15/04/2021 11:42, Tulio Magno Quites Machado Filho via Libc-alpha wrote:
> Paul E Murphy via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> 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.
>
> If we do this, we'll never be able to remove the old implementation, which was
> Adhemerval's goal.
> I particularly agree that duplicated code should be removed and I believe it
> would be helpful if libgcc had the fallback code.
>
I sent a patch to include the fallback to libgcc:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b7561b5d2443f1d5f54f5177f0fb1a13c4205856
This patch LGTM now.
Best Regards,
Raphael M Zinsly via Libc-alpha <libc-alpha@sourceware.org> writes:
> I sent a patch to include the fallback to libgcc:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b7561b5d2443f1d5f54f5177f0fb1a13c4205856
>
> This patch LGTM now.
In my previous message I mentioned that I thought that libgcc should implement
the fallback code first.
With that implemented, I have no other objections to this patch either.
Thanks!
On 14/10/2021 18:39, Tulio Magno Quites Machado Filho wrote:
> Raphael M Zinsly via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> I sent a patch to include the fallback to libgcc:
>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b7561b5d2443f1d5f54f5177f0fb1a13c4205856
>>
>> This patch LGTM now.
>
> In my previous message I mentioned that I thought that libgcc should implement
> the fallback code first.
>
> With that implemented, I have no other objections to this patch either.
>
> Thanks!
>
Thanks, I will push it upstream.
deleted file mode 100644
@@ -1,133 +0,0 @@
-/* Return backtrace of current program state.
- Copyright (C) 1998-2021 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, see
- <https://www.gnu.org/licenses/>. */
-
-#include <execinfo.h>
-#include <stddef.h>
-#include <string.h>
-#include <signal.h>
-#include <libc-vdso.h>
-
-/* This is the stack layout we see with every stack frame.
- Note that every routine is required by the ABI to lay out the stack
- like this.
-
- +----------------+ +-----------------+
- %r1 -> | %r1 last frame--------> | %r1 last frame--->... --> NULL
- | | | |
- | (unused) | | return address |
- +----------------+ +-----------------+
-*/
-struct layout
-{
- struct layout *next;
- void *return_address;
-};
-
-#define SIGNAL_FRAMESIZE 64
-
-/* Since the signal handler is just like any other function it needs to
- save/restore its LR and it will save it into callers stack frame.
- Since a signal handler doesn't have a caller, the kernel creates a
- dummy frame to make it look like it has a caller. */
-struct signal_frame_32 {
- char dummy[SIGNAL_FRAMESIZE];
- struct sigcontext sctx;
- mcontext_t mctx;
- /* We don't care about the rest, since IP value is at 'mctx' field. */
-};
-
-static inline bool
-is_sigtramp_address (void *nip)
-{
-#ifdef HAVE_SIGTRAMP_RT32
- if (nip == GLRO (dl_vdso_sigtramp_32))
- return true;
-#endif
- return false;
-}
-
-struct rt_signal_frame_32 {
- char dummy[SIGNAL_FRAMESIZE + 16];
- siginfo_t info;
- ucontext_t uc;
- /* We don't care about the rest, since IP value is at 'uc' field. */
-};
-
-static inline bool
-is_sigtramp_address_rt (void * nip)
-{
-#ifdef HAVE_SIGTRAMP_32
- if (nip == GLRO (dl_vdso_sigtramp_rt32))
- return true;
-#endif
- return false;
-}
-
-int
-__backtrace (void **array, int size)
-{
- struct layout *current;
- int count;
-
- /* Force gcc to spill LR. */
- asm volatile ("" : "=l"(current));
-
- /* Get the address on top-of-stack. */
- asm volatile ("lwz %0,0(1)" : "=r"(current));
-
- for ( count = 0;
- current != NULL && count < size;
- current = current->next, count++)
- {
- gregset_t *gregset = NULL;
-
- array[count] = current->return_address;
-
- /* Check if the symbol is the signal trampoline and get the interrupted
- * symbol address from the trampoline saved area. */
- if (is_sigtramp_address (current->return_address))
- {
- struct signal_frame_32 *sigframe =
- (struct signal_frame_32*) current;
- gregset = &sigframe->mctx.gregs;
- }
- else if (is_sigtramp_address_rt (current->return_address))
- {
- struct rt_signal_frame_32 *sigframe =
- (struct rt_signal_frame_32*) current;
- gregset = &sigframe->uc.uc_mcontext.uc_regs->gregs;
- }
- if (gregset)
- {
- if (count + 1 == size)
- break;
- array[++count] = (void*)((*gregset)[PT_NIP]);
- current = (void*)((*gregset)[PT_R1]);
- }
- }
-
- /* It's possible the second-last stack frame can't return
- (that is, it's __libc_start_main), in which case
- the CRT startup code will have set its LR to 'NULL'. */
- if (count > 0 && array[count-1] == NULL)
- count--;
-
- return count;
-}
-weak_alias (__backtrace, backtrace)
-libc_hidden_def (__backtrace)
deleted file mode 100644
@@ -1,117 +0,0 @@
-/* Return backtrace of current program state.
- Copyright (C) 1998-2021 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Library General Public License as
- published by the Free Software Foundation; either version 2 of the
- License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Library General Public License for more details.
-
- You should have received a copy of the GNU Library General Public
- License along with the GNU C Library; see the file COPYING.LIB. If
- not, see <https://www.gnu.org/licenses/>. */
-
-#include <stddef.h>
-#include <string.h>
-#include <signal.h>
-#include <stdint.h>
-
-#include <execinfo.h>
-#include <libc-vdso.h>
-
-/* This is the stack layout we see with every stack frame.
- Note that every routine is required by the ABI to lay out the stack
- like this.
-
- +----------------+ +-----------------+
- %r1 -> | %r1 last frame--------> | %r1 last frame--->... --> NULL
- | | | |
- | cr save | | cr save |
- | | | |
- | (unused) | | return address |
- +----------------+ +-----------------+
-*/
-struct layout
-{
- struct layout *next;
- long int condition_register;
- void *return_address;
-};
-
-/* Since the signal handler is just like any other function it needs to
- save/restore its LR and it will save it into callers stack frame.
- Since a signal handler doesn't have a caller, the kernel creates a
- dummy frame to make it look like it has a caller. */
-struct signal_frame_64 {
-#define SIGNAL_FRAMESIZE 128
- char dummy[SIGNAL_FRAMESIZE];
- ucontext_t uc;
- /* We don't care about the rest, since the IP value is at 'uc' field. */
-};
-
-/* Test if the address match to the inside the trampoline code.
- Up to and including kernel 5.8, returning from an interrupt or syscall to a
- signal handler starts execution directly at the handler's entry point, with
- LR set to address of the sigreturn trampoline (the vDSO symbol).
- Newer kernels will branch to signal handler from the trampoline instead, so
- checking the stacktrace against the vDSO entrypoint does not work in such
- case.
- The vDSO branches with a 'bctrl' instruction, so checking either the
- vDSO address itself and the next instruction should cover all kernel
- versions. */
-static inline bool
-is_sigtramp_address (void *nip)
-{
-#ifdef HAVE_SIGTRAMP_RT64
- if (nip == GLRO (dl_vdso_sigtramp_rt64) ||
- nip == GLRO (dl_vdso_sigtramp_rt64) + 4)
- return true;
-#endif
- return false;
-}
-
-int
-__backtrace (void **array, int size)
-{
- struct layout *current;
- int count;
-
- /* Force gcc to spill LR. */
- asm volatile ("" : "=l"(current));
-
- /* Get the address on top-of-stack. */
- asm volatile ("ld %0,0(1)" : "=r"(current));
-
- for ( count = 0;
- current != NULL && count < size;
- current = current->next, count++)
- {
- array[count] = current->return_address;
-
- /* Check if the symbol is the signal trampoline and get the interrupted
- * symbol address from the trampoline saved area. */
- if (is_sigtramp_address (current->return_address))
- {
- struct signal_frame_64 *sigframe = (struct signal_frame_64*) current;
- if (count + 1 == size)
- break;
- array[++count] = (void*) sigframe->uc.uc_mcontext.gp_regs[PT_NIP];
- current = (void*) sigframe->uc.uc_mcontext.gp_regs[PT_R1];
- }
- }
-
- /* It's possible the second-last stack frame can't return
- (that is, it's __libc_start_main), in which case
- the CRT startup code will have set its LR to 'NULL'. */
- if (count > 0 && array[count-1] == NULL)
- count--;
-
- return count;
-}
-weak_alias (__backtrace, backtrace)
-libc_hidden_def (__backtrace)
@@ -71,17 +71,6 @@ PROCINFO_CLASS int (*_dl_vdso_clock_getres_time64) (clockid_t,
# ifdef HAVE_GET_TBFREQ
PROCINFO_CLASS uint64_t (*_dl_vdso_get_tbfreq)(void) RELRO;
# endif
-/* The sigtramp are used on powerpc backtrace without using
- INLINE_VSYSCALL, so there is no need to set their type. */
-# ifdef HAVE_SIGTRAMP_RT64
-PROCINFO_CLASS void *_dl_vdso_sigtramp_rt64 RELRO;
-# endif
-# ifdef HAVE_SIGTRAMP_RT32
-PROCINFO_CLASS void *_dl_vdso_sigtramp_rt32 RELRO;
-# endif
-# ifdef HAVE_SIGTRAMP_32
-PROCINFO_CLASS void *_dl_vdso_sigtramp_32 RELRO;
-# endif
#endif
#undef RELRO
@@ -47,15 +47,6 @@ setup_vdso_pointers (void)
#ifdef HAVE_GET_TBFREQ
GLRO(dl_vdso_get_tbfreq) = dl_vdso_vsym (HAVE_GET_TBFREQ);
#endif
-#ifdef HAVE_SIGTRAMP_RT64
- GLRO(dl_vdso_sigtramp_rt64) = dl_vdso_vsym (HAVE_SIGTRAMP_RT64);
-#endif
-#ifdef HAVE_SIGTRAMP_RT32
- GLRO(dl_vdso_sigtramp_rt32) = dl_vdso_vsym (HAVE_SIGTRAMP_RT32);
-#endif
-#ifdef HAVE_SIGTRAMP_32
- GLRO(dl_vdso_sigtramp_32) = dl_vdso_vsym (HAVE_SIGTRAMP_32);
-#endif
}
#endif
@@ -252,11 +252,4 @@
#define HAVE_GETTIMEOFDAY_VSYSCALL "__kernel_gettimeofday"
#define HAVE_GET_TBFREQ "__kernel_get_tbfreq"
-#if defined(__PPC64__) || defined(__powerpc64__)
-# define HAVE_SIGTRAMP_RT64 "__kernel_sigtramp_rt64"
-#else
-# define HAVE_SIGTRAMP_32 "__kernel_sigtramp32"
-# define HAVE_SIGTRAMP_RT32 "__kernel_sigtramp_rt32"
-#endif
-
#endif /* _LINUX_POWERPC_SYSDEP_H */