From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 245C1384A07D for ; Fri, 26 Feb 2021 17:39:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 245C1384A07D Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11QHYb7B093415; Fri, 26 Feb 2021 12:39:15 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 36y02t3nbx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 12:39:15 -0500 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 11QHZdDb100709; Fri, 26 Feb 2021 12:39:15 -0500 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 36y02t3nbj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 12:39:15 -0500 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 11QHc79u008533; Fri, 26 Feb 2021 17:39:14 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma04dal.us.ibm.com with ESMTP id 36y4130r40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 17:39:14 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 11QHdDLD24576352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Feb 2021 17:39:13 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9ADE2112061; Fri, 26 Feb 2021 17:39:13 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 84261112064; Fri, 26 Feb 2021 17:39:12 +0000 (GMT) Received: from work-tp (unknown [9.65.223.199]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Fri, 26 Feb 2021 17:39:12 +0000 (GMT) Date: Fri, 26 Feb 2021 14:39:09 -0300 From: Raoni Fassina Firmino To: Adhemerval Zanella Cc: Florian Weimer , Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH] powerpc: Remove backtrace implementation Message-ID: <20210226173909.nikuk5bohko2clqj@work-tp> Mail-Followup-To: Adhemerval Zanella , Florian Weimer , Adhemerval Zanella via Libc-alpha 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> <87blcbx91u.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-26_05:2021-02-26, 2021-02-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102260130 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, 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: Fri, 26 Feb 2021 17:39:17 -0000 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).