From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111151 invoked by alias); 3 May 2019 19:45:25 -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 111105 invoked by uid 89); 3 May 2019 19:45:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=H*f:sk:877eb7q, H*i:sk:877eb7q X-HELO: aserp2130.oracle.com Received: from aserp2130.oracle.com (HELO aserp2130.oracle.com) (141.146.126.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 May 2019 19:45:22 +0000 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43JhbTX087995; Fri, 3 May 2019 19:44:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : mime-version : content-type; s=corp-2018-07-02; bh=by7MuWFa3IFCUZ9ZPh0iHKLx4Og6jfka+hFPJwy7BCQ=; b=DoBe/wXRYkaioH8N+Q8GoBhewCAboP2aNoZjXFcTiR5UBhuZN+8tv/q3xuPMpZqtasK/ psKVpxozbni6Ymn85NZ2WachKyjn9dpIoCvSfrIhUjB7MojFmabMhFnXGjVWXE3QZIG/ 7VhAPw1T8Nj4LJXn+SQaOj459vzgxjfoHGynDyUM1Gq2QJNKkCLgNaz38ZuX9drprVeL 6iUZZXaZh85Dt/E0HXvJjzbSopOaK9QY2DTRQTG9nZYPw+dRYO5AFyU1CYuTq4Wno4ab UkzTFIGYAdYMyydXirpO12KHS1E457cyAHbDDrFY5K/dt3VisSJg5MVn0JkRicok3yks Iw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2130.oracle.com with ESMTP id 2s6xhyrv2f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 19:44:59 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43JhCPj134146; Fri, 3 May 2019 19:44:58 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2s6xhht8p1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 19:44:58 +0000 Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x43Jiv7L031279; Fri, 3 May 2019 19:44:57 GMT Received: from loom (/81.187.191.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 May 2019 12:44:56 -0700 From: Nick Alcock To: Florian Weimer 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> Date: Fri, 03 May 2019 19:45:00 -0000 In-Reply-To: <877eb7qznt.fsf@oldenburg2.str.redhat.com> (Florian Weimer's message of "Fri, 03 May 2019 18:19:02 +0200") Message-ID: <87bm0juxu1.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00121.txt.bz2 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). Even the backtrace section, if and when we add it, isn't going to do what DWARF unwinding info does: its purpose is more to let debuggers find function arguments' values and types on the call stack in a form much smaller than DW_TAG_call_site. Wherever possible, if we find we need something the unwinding info is providing, we'll point into that instead, to save space. The one overriding rule of CTF is 'never duplicate anything you can find elsewhere'. We already use strings from the ELF string table whenever possible: if we ever come to need unwinding info, we'll definitely use the DWARF unwinding info, because it is not stripped from binaries, so its presence can be relied upon. (Also, CTF is meant to be very small, small enough to ignore and to leave even in stripped binaries except in very constrained environments. I'm almost certain that it'll be *much* smaller than the DWARF unwinding information. It certainly is in all cases I've examined so far. But you're wise to reserve judgement on this until we have GCC and linker support in place so you can see it for yourself.)