[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7aebea1d-b662-75c4-14cb-b614ff1aac9f@dereferenced.org>
Date: Sat, 17 Jul 2021 14:52:48 -0500 (CDT)
From: Ariadne Conill <ariadne@...eferenced.org>
To: musl@...ts.openwall.com
cc: Timo Teras <timo.teras@....fi>
Subject: Re: option to enable eh_frame
Hello,
On Sat, 17 Jul 2021, Rich Felker wrote:
> On Sat, Jul 17, 2021 at 06:40:10PM +0300, Timo Teras wrote:
>> On Sat, 17 Jul 2021 09:25:44 -0400
>> Rich Felker <dalias@...c.org> wrote:
>>
>>>> Please add in any reasons I may have missed. I would like to have
>>>> your complete list of reasons why to remove .eh_frame. So far it
>>>> has been coming out in pieces. I'd like constructive discussion if
>>>> some of these items could be implemented stronger in other means
>>>> than removing ..eh_frame.
>>>
>>> You're coming at it from the wrong direction. For new, nonstandard
>>> functionality requests, musl has a well established process of
>>> criteria for inclusion and exclusion, based on invasiveness (this is
>>> not just a matter of code change size, but of constraints it imposes),
>>> size, how often the lack of the functionality impacts portable or
>>> important FOSS programs users want to run on musl, and whether there
>>> are other ways the applications that want it could achieve what they
>>> want. In this case, all of those criteria indicate against doing it.
>>
>> Just to be on record, musl used to include .eh_frame until 2012 and
>> commit b439c051c7eee4eb4b93fc382f993aa6305ce530 or musl 0.9.5. So back
>> then existing "contract" was broken. If this discussion was done then,
>> this would be the other angle: why to break something that is working.
>
> You're still missing the point. Having it there when it just happened
> to be (and likewise on archs where there's some weird non-DWARF unwind
> table that we haven't opted out of) is not a contract to support it;
> it's an artifact of the toolchain. *Explicitly making a change for the
> purpose of adding it*, with no other plausible purpose, is such a
> contract.
>
> By the way, I think you're slightly wrong on the history. Prior to
> that commit, unwind info was already omitted unless debugging was
> enabled; this was because I was not aware that GCC would emit it in
> .debug_frame if needed.
>
>>>> But fundamentally I think if we ship .debug_frame, all people
>>>> wanting do backtrace() and the silly stuff, will just enable
>>>> .debug_frame support in their code and still do the silly stuff in
>>>> worse way, than if .eh_frame was enabled. Since technically they
>>>> are the same, even if the intended use case is different. As seen
>>>> libunwind does have --enable-debug-frame.
>>>
>>> They might, but then they're clearly using a debugging interface that
>>> only works when debug files are available (or if you include this in
>>> main libc.so, when libc.so is not stripped).
>>
>> But how is this different from the "contract" viewpoint?
>>
>> You are agreeable to have .debug_frame by default in the main DSO. And
>> if we make musl have .debug_frame, and build libunwind with
>> --enable-debug-frame, the user gets quite similar "contract" experience
>> as with .eh_frame. But just worse than having .eh_frame, because for the
>> unwinder to be able to use .debug_frame it needs to do more silly
>> things.
>
> It needs to do "silly" things which explicitly break if debug info is
> stripped, making it clear that this is not functionality of the libc
> but (strippable) debugging metadata that can't be relied on.
>
>> Users don't care if it's .debug_frame or .eh_frame as long as the higher
>> level functionality works. And it gives same "de facto contract"
>> experience.
>>
>> Sorry for being "stupid" here, but I'm trying to understand your
>> viewpoint. So far it's sounding like:
>> - same things can be achieved by doing X or Y
>> - you argue X is evil and breaking contract, but Y is ok
>> - on system/user level the "contract" or "experience" is same
>> regardless of doing X or Y
>>
>> Basically I'm trying to understand why do you consider .eh_frame so
>> much more important "contract" than .debug_frame?
>
> Because .eh_frame is part of the loaded program segment that ELF
> semantics define as being available to the runtime (which is what
> makes it non-strippable), and .debug_frame is not.
In this case, wouldn't we want to emit .eh_frame for libc.so? If not,
why? If it's supposed to be available, that seems like a more compelling
argument for including it, not excluding it.
Ariadne
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
