From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3404 invoked by alias); 1 Dec 2016 11:33:16 -0000 Mailing-List: contact infinity-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: infinity-owner@sourceware.org Received: (qmail 3387 invoked by uid 89); 1 Dec 2016 11:33:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=opaque, anticipated, stripped, balance X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Date: Thu, 01 Dec 2016 11:33:00 -0000 From: Gary Benson To: infinity@sourceware.org Cc: Nathan Sidwell , "Carlos O'Donell" , roland@hack.frob.com Subject: Re: infinity notes Message-ID: <20161201113300.GA10328@blade.nx> References: <895c816f-39d7-0aae-1400-db68d37d3712@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <895c816f-39d7-0aae-1400-db68d37d3712@acm.org> Organization: Red Hat UK Ltd, 64 Baker Street, 4th Floor, W1U 7DF, UK. Registered in England and Wales (3798903) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 01 Dec 2016 11:33:03 +0000 (UTC) X-SW-Source: 2016-q4/txt/msg00002.txt.bz2 Hi Nathan, Nathan Sidwell wrote: > Gary, > I was impressed by the infinity notes presentation and examples. > I was the one who asked 'why not debug section?'. Thinking > further I think they should be debug sections rather than notes. > > IIUC the choice of notes was for two reasons: > 1) debug sections get removed by strip -g. > 2) you expect infinity to grow beyond plain debugging. > > Please correct me if I'm wrong. > > For #1 isn't that what you want? We have separated debug info, so a > .debug-infinity section could still be located in the same way debug > info would be for a stripped executable. It'll be a poor debug > experience just having the infinity notes. Admittedly not as bad as > not having them, but why elevate some debug information above other > info? It seems odd to me to make these things 'more important' than > say, line info. > > The notes are 'only a few K', but embedded targets complain about > every extra size increase (both on-disk and in-memory), and this > sounds like a whole page. The reasoning has evolved over time, but it's mainly that Infinity functions exist to replicate functionality currently provided by libthread_db, and requiring debuginfo to access them would be a significant behaviour change from libthread_db. It's not quite a non-issue for debuggers because plenty of users build their own programs with debuginfo but do not install system debuginfo--it's a fairly common use case to not have libpthread.so debuginfo available. Also, I understand libthread_db is used by tools other than debuggers, though I don't have examples to hand. I appreciate that embedded users will be unhappy with any increase in size, but I also appreciate that there are other users who would be unhappy if they had to install debuginfo where they didn't before. I'm trying to balance everyone's needs with this. > Which leads me to #2. If infinity extends to more things, the > notes are only going to get bigger. That'll lead to pressure > to have some kind of separated notes capability. Why not > future proof things now by using a debug section? This is true, and in all honesty I hadn't anticipated the number of possible uses people would come up with for this. The notes are just opaque blocks of data that clients feed to the Infinity library. There's no specific requirement on where they come from, and its certainly possible to imagine glibc, for example, having configure options to specify what section the notes get built into, so regular distributions could build with unstripped notes, and embedded distributions could build with notes that get stripped into separated debuginfo. Its also possible to imagine that different notes could go in different places in the same build, so you could have very debugger-specific notes like pretty-printer accessors in debuginfo, and more general purpose notes like the thread debug ones unstripped. > On the downside, I know ELF eschews magical section names, so I > guess there could be pushback there. However, a magical > '.debug_infinity' section probably conveys more information than > 'unknown note #5'. The "unknown note #5" you saw at Cauldron will go away once tools are updated to recognise the notes. I have patches ready to go for binutils, and I'll likely update elfutils too once everything's more fixed. Thanks, Gary -- https://infinitynotes.org/