From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119708 invoked by alias); 6 May 2019 12:07:07 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 119694 invoked by uid 89); 6 May 2019 12:07:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=day X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 May 2019 12:07:05 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D401185541; Mon, 6 May 2019 12:07:04 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-103.ams2.redhat.com [10.36.116.103]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 00E9327091; Mon, 6 May 2019 12:07:03 +0000 (UTC) From: Florian Weimer To: Nick Alcock Cc: binutils@sourceware.org Subject: Re: [PATCH 00/19] libctf, and CTF support for objdump and readelf References: <20190430225706.159422-1-nick.alcock@oracle.com> <877eb7qznt.fsf@oldenburg2.str.redhat.com> <87bm0juxu1.fsf@esperi.org.uk> Date: Mon, 06 May 2019 12:07:00 -0000 In-Reply-To: <87bm0juxu1.fsf@esperi.org.uk> (Nick Alcock's message of "Fri, 03 May 2019 20:44:54 +0100") Message-ID: <87r29beqhl.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00138.txt.bz2 * Nick Alcock: > On 3 May 2019, Florian Weimer verbalised: > >> * Nick Alcock: >> >>> - a very compact association between the ELF symbol table and CTF. >>> No symbol table indexes are recorded: all are implied: the >>> data-object section is as compact as possible, containing nothing >>> but a stream of type IDs describing the type of data symbols in >>> symbol table order. >> >> Is this for GNU/Linux? >> >> On GNU/Linux, DWARF unwinding information (in the form of >> PT_GNU_EH_FRAME) is not optional, it is required by the ABI (although >> many people pretend it's not, resulting in crashes or worse). >> >> I'm worried that we have to add both in the future, DWARF data and CTF >> data, which would be rather bad. > > I'm fairly sure they are quite distinct. CTF doesn't even try to record > unwinding information, or anything like it, but rather lets you > introspect into datatypes (not into the call stack, not into function > arguments, but into C types). I don't know what happened on Friday. I must have had a bad day. (I did have trouble backporting something that should have been a straightforward fix, too.) I suppose I somehow mixed up CTF and CFI in my mind. Sorry about that. You are of course right, CTF isn't related to unwinding. Thanks, Florian