From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86350 invoked by alias); 8 May 2019 11:39:29 -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 86339 invoked by uid 89); 8 May 2019 11:39:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=HX-Languages-Length:3908, circular X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 May 2019 11:39:28 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x48BOaFD050823; Wed, 8 May 2019 11:39:26 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=SXyy3JF2Fbsqs2vQj/dvbadtVTgvXNcPRgdCOTBJKbQ=; b=gQiNzIPSVMLoHl96WrAhvxG774wh3oUloctjxG8UqPvuAg1mdMYjxhgueHcLbhaVrPne 1bLFWoRxs5Ev5CO+Aa/SIfXihnpAcDAXOoVR2PgiEyaJ7XtnhxZFUjRmsGjanLXLBkVc S52rO8+bL4F4HnB+hs9ISPqagj1RCj3ExOXorymZQoVMpazBNK1oBOEumlbDvtPD/nB6 hAeldA+y3aRbsoefZDeWuB1vPbYWvJDl5L2MNhz3idNa6vLNeB9UEvhZa+BK2L2D3VNW YT3PSBdL5YSHX6p/SF/cDbe2x/rwSYeJDHYTNx8I+Q4JjHKr/8qolYOL15XdLiDMsVfb RQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2s94b0u7cp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 May 2019 11:39:26 +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 x48BdPNX007199; Wed, 8 May 2019 11:39:25 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2s94ag1ch2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 May 2019 11:39:25 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x48BdOG4014648; Wed, 8 May 2019 11:39:24 GMT Received: from loom (/81.187.191.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 May 2019 04:39:23 -0700 From: Nick Alcock To: Joseph Myers Cc: 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> Date: Wed, 08 May 2019 11:39:00 -0000 In-Reply-To: (Joseph Myers's message of "Tue, 7 May 2019 21:28:31 +0000") Message-ID: <8736lprx92.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/msg00149.txt.bz2 On 7 May 2019, Joseph Myers said: > On Fri, 3 May 2019, Nick Alcock wrote: > >> > This means libctf should be portable to the same range of hosts as >> > binutils, all of which can be used as hosts for cross toolchains for a >> > range of targets (ELF and non-ELF). For example, it should be portable to >> > hosts such as MinGW or OS X. >> >> Seems sensible. It might lose some functionality, though, at least to >> start with. (Say, sharing string tables with the overarching container, >> opening CTF files by handing them an fd to a containing binary, etc. >> There are alternatives callers can use in all these cases.) > > I don't think that functionality should depend on the host, though it > might depend on the target. I agree with all of that. We don't want cross-tools to generate different output to non-cross tools, etc. I guess that means I might *have* to figure out how to do the (very limited) ELFish things currently being done with libelf with bfd instead. (And I just noticed that bfd does in fact have useful texinfo, so I can read that and most of my bfd fear should go away. I have no *idea* why I thought it had no texinfo docs. Probably some out of date fifteen year old memory fooling me or something.) ... ok with docs BFDizing this should be much less terrifying than I thought. I was also a bit worried about circular dependencies, but I don't think there are any: we'll have {ld, binutils, gdb} -> libctf -> bfd, which is fine, but no link from bfd back to libctf. >> I'll probably arrange for the deduplicating linker plugin to be >> ELF-only, at least to start with, because I have no way to test on > > A plugin is about the only thing I'd expect to depend on the host (in that > you'd need different build system logic to build a non-ELF shared object). Yes, except that if the host is horribly limited I'm starting to not care about it. If mingw *does* have writable memory mappings, I'm happy... >> If there are really still platforms relevant outside industrial museums >> without mmap(), we can rethink this, but I bet there aren't, or that any >> such platforms aren't going to be storing huge numbers of CTF containers >> in any case. (The use case for this is if you have so many TUs that you >> can't store one per section without risking blowing the 64K section >> limit. Any machine new enough to be dealing with anything in that size >> range is going to have mmap() as well, right? Or something we can use >> instead of it with similar semantics...) > > MinGW has similar APIs such as MapViewOfFile. It's not mmap. ... and that's near enough I think. It looks like you can at least use it to create files via ordinary memory I/O, just like mmap(): it has weird restrictions but they're no harder to deal with than the page-granularity restrictions that go with mmap() anyway. So I don't need to rewrite all the archive code to use file I/O instead :) >> 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. > > I don't see why such functions should depend on whether the host is ELF at > all. On the target, yes, but not on the host. Oh true. I've constantly mixed up host and target for as long as I've been using GNU tools, and I fear that after 25 years of getting it wrong I'm not going to start getting it right any time soon. (I don't know why. It's not as if the names are unclear.) I did, of course, mean 'target' there, which does mean BFDizing to drop the elfutils dependency. I'll look at that soon. (Most of the other issues you raised I have already fixed locally, and the fixes will be in the next patch rev.)