From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91657 invoked by alias); 3 May 2019 11:23:20 -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 91646 invoked by uid 89); 3 May 2019 11:23:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=aim, nearly, sk:automat, Our 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 11:23:19 +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 x43B9XtI037764; Fri, 3 May 2019 11:23:08 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=evxBR23xCxVOtTj2/0+i7IQ4Zzk5rZtzOnDqTBZTKc8=; b=pa+j244zCifNRESR1fhoR8hqKBM1/PPNh8WHScSgBtSTsXueiqaHBrq2jMDa0W1eX5Ve iYhY2EBmKafmPakXnJiiRvCxnGMZ2onuRxuI73id9ny/3aK4ONxKAxYK9zSNCO6s+DQs +6F+irPHHO8zKxvm1bErYzxI9AV7opgfhBlQt0LrcS6GdoN5xetrgYbJEImrbcBhPKLR Bf7ShlmPSWBP0bHdmb6yG4YRVospgNUm4MojqkqN3gFHfrd2tiyD7hz8Eg4RC76jSnIv RF+7T2uRtjwD20NPLRzeepeZ47PDcNCAlkWwsfBgiCofWTydTqGjQ4FHE4CloQXBZRpD rg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 2s6xhyp30g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 11:23:08 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43BN2LC158565; Fri, 3 May 2019 11:23:07 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2s6xhhakur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 11:23:07 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x43BN6C9031894; Fri, 3 May 2019 11:23:06 GMT Received: from loom (/81.187.191.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 May 2019 04:23:05 -0700 From: Nick Alcock To: Nick Clifton Cc: binutils@sourceware.org Subject: Re: [PATCH 02/19] include: new header ctf-api.h References: <20190430225706.159422-1-nick.alcock@oracle.com> <20190430225706.159422-3-nick.alcock@oracle.com> <863e1bbe-c59f-5256-ed33-01f38af717f0@redhat.com> Date: Fri, 03 May 2019 11:23:00 -0000 In-Reply-To: <863e1bbe-c59f-5256-ed33-01f38af717f0@redhat.com> (Nick Clifton's message of "Thu, 2 May 2019 16:07:37 +0100") Message-ID: <87a7g3wzmv.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/msg00112.txt.bz2 On 2 May 2019, Nick Clifton verbalised: > Hi Nick, > >> This non-installed header is the means by which libctf consumers >> communicate with libctf. > > By "non-installed" do you mean that it would not be placed into /usr/include ? Yes. Mostly because I assumed that the bar was higher for installed headers than for non-installed ones, and there are no users of libctf yet. > If so, then how do consumers know how to communicate with libctf, given that > they might be compiled without access to the ctf sources ? At the moment, libctf is an automatically-synched copy of the upstream libdtrace-ctf project. Our aim is to eventually make binutils the upstream, whereupon we can drop libdtrace-ctf entirely, and turn this into an installed header :) (If we do make it an installed header, we want to set up things like symbol versioning first. libdtrace-ctf already has all of that.) >> +/* Clients can open one or more CTF containers and obtain a pointer to an >> + opaque ctf_file_t. Types are identified by an opaque ctf_id_t token. >> + They can also open or create read-only archives of CTF containers in a >> + ctf_archive_t. > > Are CTF archives just arbitrary collections of CTF containers or is there more > to them than that ? They are usually arbitrary collections of *related* CTF containers (with associated names): e.g. a parent container and a bunch of children that reuse types from the parent. The format is given in ctf-impl.h: it's just an mmappable archive which isn't tar or cpio and so doesn't have to deal with the infinite horrors of tar or cpio versioning. :) One feature it does have that tar and cpio don't is that, like zip files, the compression happens at the level of individual archive members, via the CTF_F_COMPRESS flag bit in the header. This means that you can elect to not compress CTF files that are already "small enough" (say, smaller than a page), whereupon they can get read via mmap() directly out of the CTF archive, with no copying or decompression overhead. CTF files with parents are often very small: looking at Linux kernel 5.0, of 2938 CTF files in the archive I generated in my most recent test build, all but 188 are under 4096 bytes: but they all have as a parent the 1.2MiB shared CTF file that contains types shared across kernel modules (in a non-kernel context, the parent container will usually contain types shared across TUs). (Nearly 2000 of them are under 512 bytes long. By this stage just the gzip header is bloating the thing up substantially, and you gain nothing from compression of things so small.)