From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id EF9F7388CC04 for ; Tue, 23 Feb 2021 12:27:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EF9F7388CC04 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-293--5VE1ckEO9WMxu6oPvQIPQ-1; Tue, 23 Feb 2021 07:27:49 -0500 X-MC-Unique: -5VE1ckEO9WMxu6oPvQIPQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D38DB804023; Tue, 23 Feb 2021 12:27:47 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-131.ams2.redhat.com [10.36.113.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE8BD5D9D0; Tue, 23 Feb 2021 12:27:46 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH] powerpc: Remove backtrace implementation References: <20210212170941.1786380-1-adhemerval.zanella@linaro.org> <878s7ti4m0.fsf@oldenburg.str.redhat.com> <90d1d0e5-a31e-fbac-ead0-7f76f2645cd9@linaro.org> <87sg5n3g04.fsf@linux.ibm.com> Date: Tue, 23 Feb 2021 13:28:29 +0100 In-Reply-To: (Adhemerval Zanella via Libc-alpha's message of "Tue, 23 Feb 2021 08:56:22 -0300") Message-ID: <87blcbx91u.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:27:52 -0000 * 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