From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id BA023395B41C for ; Fri, 13 May 2022 13:08:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA023395B41C Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id EA7371F94B; Fri, 13 May 2022 13:08:40 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E56372C142; Fri, 13 May 2022 13:08:40 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id DB28C639D; Fri, 13 May 2022 13:08:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id DA378634E; Fri, 13 May 2022 13:08:40 +0000 (UTC) Date: Fri, 13 May 2022 13:08:40 +0000 (UTC) From: Michael Matz To: Indu Bhagat cc: binutils@sourceware.org Subject: Re: [PATCH,RFC 0/7] Definition and Implementation of CTF Frame format In-Reply-To: <20220507005223.3093035-1-indu.bhagat@oracle.com> Message-ID: References: <20220507005223.3093035-1-indu.bhagat@oracle.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 13:08:42 -0000 Hello, On Fri, 6 May 2022, Indu Bhagat via Binutils wrote: > PT_GNU_CTF_FRAME) in ELF linked binaries. The CTF Frame format specifies the > minimal necessary unwind information, i.e., information needed to recover only > the CFA and the return address (RA) for all insns of a program. This > information is a subset of what .eh_frame can convey: .eh_frame specifies how > to resurrect all callee-saved registers, if need be. So, it's designed to be less complete than .eh_frame. That in itself is not a problem, but ... > ratio = (.ctf_frame / (.eh_frame+.eh_frame_hdr)) > > --------------------------------------------------- > program | [x86_64] ratio | [aarch64] ratio > --------------------------------------------------- > addr2line | 1.13 | 0.67 > ar | 1.03 | 0.70 > as | 1.00 | 0.73 > c++filt | 1.08 | 0.64 > elfedit | 1.03 | 0.66 > gprof | 1.06 | 0.71 > ld | 1.02 | 0.73 > nm | 1.07 | 0.69 > objcopy | 1.08 | 0.72 > objdump | 1.08 | 0.73 > size | 1.10 | 0.67 > strings | 1.09 | 0.67 ... this is. You need more space on x86-64 to store severely less information, and even on aarch64 the savings are meager when compared to the information loss. So, hmm, who would want to ever enable .ctf_frame instead of .eh_frame? Ciao, Michael.