public inbox for infinity@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: infinity@sourceware.org
Cc: Nathan Sidwell <nathan@acm.org>,
	"Carlos O'Donell" <carlos@systemhalted.org>,
	roland@hack.frob.com
Subject: Re: infinity notes
Date: Thu, 01 Dec 2016 11:33:00 -0000	[thread overview]
Message-ID: <20161201113300.GA10328@blade.nx> (raw)
In-Reply-To: <895c816f-39d7-0aae-1400-db68d37d3712@acm.org>

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/

       reply	other threads:[~2016-12-01 11:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <895c816f-39d7-0aae-1400-db68d37d3712@acm.org>
2016-12-01 11:33 ` Gary Benson [this message]
2016-12-01 13:26   ` Carlos O'Donell
2016-12-02 12:55   ` Nathan Sidwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161201113300.GA10328@blade.nx \
    --to=gbenson@redhat.com \
    --cc=carlos@systemhalted.org \
    --cc=infinity@sourceware.org \
    --cc=nathan@acm.org \
    --cc=roland@hack.frob.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).