From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31298 invoked by alias); 24 May 2019 16:05:14 -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 31288 invoked by uid 89); 24 May 2019 16:05:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=H*f:sk:3ce5d56, H*i:sk:3ce5d56, thusly X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 May 2019 16:05:13 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4OFrnaY057246; Fri, 24 May 2019 16:04:48 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=oAGfT2pTSOm7e8EQdsAanr9cZhp3nsHvEugvYsOzvbI=; b=J4398F+2l+vx7OCS9ybN3dbYbWh/f6hvMm5PUaZQ7Y3HSuxofLSHBJyfZIleqfgF5KIe 6Wlz/GKcpvcEINIoQ61mhtQZqyozy2/TQ+4CoZq4yf+bemZlsDH5KMEN33efMZvfeMEN kSksN861eZizgK/ENtb/RcMNUJPkxTbSiOodROlqPHHFFT2BWb4OT138mmo/CvFPZ3R9 zQkBcAWpQ2YgjP8HineJ1I7Ph48+rNz6YX6QspxqRDsxhvaUkcfEOJusjBm7Zhx5m+pc BVQNrqkIXv1fZlZBabYBduiDoxUdXiDtLrUrrt/y8cNuFoaWbBPOsTqpFXFMxYepRy6u 8Q== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2smsk5t280-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 May 2019 16:04:48 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4OG3eSJ075828; Fri, 24 May 2019 16:04:47 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2smsgtycpp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 May 2019 16:04:47 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4OG4kvN003403; Fri, 24 May 2019 16:04:46 GMT Received: from loom (/81.187.191.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2019 16:04:45 +0000 From: Nick Alcock To: Pedro Alves Cc: Joseph Myers , binutils@sourceware.org Subject: Re: [PATCH 00/19] libctf, and CTF support for objdump and readelf References: <20190430225706.159422-1-nick.alcock@oracle.com> <8736lvwr9p.fsf@esperi.org.uk> <3ce5d56c-8cb1-7d66-f3aa-53e53050baf9@redhat.com> Date: Fri, 24 May 2019 16:05:00 -0000 In-Reply-To: <3ce5d56c-8cb1-7d66-f3aa-53e53050baf9@redhat.com> (Pedro Alves's message of "Fri, 24 May 2019 09:57:17 +0100") Message-ID: <87o93rbzz8.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/msg00347.txt.bz2 On 24 May 2019, Pedro Alves spake thusly: > On 5/3/19 3:23 PM, Nick Alcock wrote: >>> * Use of elf.h. Non-ELF hosts won't have such a header. You should be >>> working with the existing include/elf/*.h definitions of ELF data >>> structures in binutils. >> This is all for build hosts that aren't ELF, right? I don't think we can >> reasonably expect ctf_open() or ctf_fdopen() to work for anything but >> raw CTF files on non-ELF hosts, given that by their very nature these >> functions are getting CTF data out of ELF sections, and non-ELF formats >> don't necessarily support anything like the named section concept ELF >> has got at all. >> >> The only other ELF-specificity is looking up types by symbol table >> offset. Again, I don't know enough about non-ELF platforms to know if >> this concept is even practical there, which would mean the data object >> and function info sections would be empty on such hosts, and >> ctf_lookup_by_symbol(), ctf_func_info() and ctf_func_args() would not >> function or would be excluded from the set of exported symbols entirely. >> >> This would reduce libctf's utility, but not eliminate it: external >> systems can still look up types by name or CTF type ID even if they >> can't do it by symbol. > > Even if you only want to support CTF on ELF containers, a cross > binutils build hosted on e.g., Windows, targeting an ELF port, should > still be able to use the CTF. That's why it is important to not rely > on host headers for ELF definitions. It wasn't clear to me from > your remarks above whether the cross use case is considered? My v2 posting (already out) and v3 (to be posted today, with a bfdization layer that actually works and a bunch of interface changes to make it more useful, and an example use in objdump) appear in my testing to work on mingw, at least. I think that's a non-ELF-capable host. Avoiding relying on host ELF headers is also important because the ELF header I was unthinkingly relying on isn't portable outside glibc on Linux and perhaps Solaris, and that's definitely not portable enough. (We do still *need* a few lines of stuff from ELF headers, because the low-level symbol lookup parts of libctf cannot rely on having a bfd available, so we have to do symbol walkiing by hand -- but we don't need the host to provide those few lines, and we do use BFD to get section content etc when possible now.)