From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B8E12385702C for ; Wed, 14 Apr 2021 21:37:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8E12385702C Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13ELXj4d002496; Wed, 14 Apr 2021 17:37:34 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 37x1pmkkf4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Apr 2021 17:37:34 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 13ELXpSR002830; Wed, 14 Apr 2021 17:37:33 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 37x1pmkkeu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Apr 2021 17:37:33 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 13ELHxk1019322; Wed, 14 Apr 2021 21:37:32 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma01dal.us.ibm.com with ESMTP id 37u3n9wdcm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Apr 2021 21:37:32 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 13ELbVRv17760704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Apr 2021 21:37:31 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D6D48112063; Wed, 14 Apr 2021 21:37:31 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 961A0112061; Wed, 14 Apr 2021 21:37:31 +0000 (GMT) Received: from [9.85.151.16] (unknown [9.85.151.16]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 14 Apr 2021 21:37:31 +0000 (GMT) Subject: Re: [PATCH] powerpc: Remove backtrace implementation To: Adhemerval Zanella , Florian Weimer , Adhemerval Zanella via Libc-alpha , Tulio Magno Quites Machado Filho 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> <20210226173909.nikuk5bohko2clqj@work-tp> From: Paul E Murphy Message-ID: <57f96ee4-7586-de09-2234-ad09c347be84@linux.ibm.com> Date: Wed, 14 Apr 2021 16:37:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210226173909.nikuk5bohko2clqj@work-tp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BKvcXcKJVxDUsFQ4BdRiFti2z-VaYBL1 X-Proofpoint-ORIG-GUID: MZDQs9Hns7gQ_RB8SBFnPjg3BSdEEeeZ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-14_12:2021-04-14, 2021-04-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1011 mlxscore=0 adultscore=0 priorityscore=1501 impostorscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104140138 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, 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: Wed, 14 Apr 2021 21:37:37 -0000 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.