* Re: infinity notes
[not found] <895c816f-39d7-0aae-1400-db68d37d3712@acm.org>
@ 2016-12-01 11:33 ` Gary Benson
2016-12-01 13:26 ` Carlos O'Donell
2016-12-02 12:55 ` Nathan Sidwell
0 siblings, 2 replies; 3+ messages in thread
From: Gary Benson @ 2016-12-01 11:33 UTC (permalink / raw)
To: infinity; +Cc: Nathan Sidwell, Carlos O'Donell, roland
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: infinity notes
2016-12-01 11:33 ` infinity notes Gary Benson
@ 2016-12-01 13:26 ` Carlos O'Donell
2016-12-02 12:55 ` Nathan Sidwell
1 sibling, 0 replies; 3+ messages in thread
From: Carlos O'Donell @ 2016-12-01 13:26 UTC (permalink / raw)
To: Gary Benson; +Cc: infinity, Nathan Sidwell, Roland McGrath
On Thu, Dec 1, 2016 at 6:33 AM, Gary Benson <gbenson@redhat.com> wrote:
> 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.
I agree completely.
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: infinity notes
2016-12-01 11:33 ` infinity notes Gary Benson
2016-12-01 13:26 ` Carlos O'Donell
@ 2016-12-02 12:55 ` Nathan Sidwell
1 sibling, 0 replies; 3+ messages in thread
From: Nathan Sidwell @ 2016-12-02 12:55 UTC (permalink / raw)
To: Gary Benson, infinity; +Cc: Carlos O'Donell, roland
Gary,
> 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.
Yeah, I can see that's a challenge.
> 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.
That flexibility is good. It might be wise to document it early on with
an example design at least -- so that those who add additional
functionality don't blindly add new NOTES segments.
> 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.
Right. My point was that someone without an updated tool might be more
informed. (Hey, if you have users who don't want debug info, I'll have
ones that have old tools!)
Anyway, it seems like you're thinking about the issue, which is great!
nathan
--
Nathan Sidwell
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-12-02 12:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <895c816f-39d7-0aae-1400-db68d37d3712@acm.org>
2016-12-01 11:33 ` infinity notes Gary Benson
2016-12-01 13:26 ` Carlos O'Donell
2016-12-02 12:55 ` Nathan Sidwell
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).