From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2283 invoked from network); 17 Jul 2021 19:53:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2021 19:53:05 -0000 Received: (qmail 26269 invoked by uid 550); 17 Jul 2021 19:53:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26242 invoked from network); 17 Jul 2021 19:53:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dereferenced.org; s=mailbun; t=1626551569; bh=oRiPk2KPjbzb0sZZsJeY4R2XfeEZlAHbKR3Lfjug+Do=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bwWKiueXfVlcXYFs6TFyb+hx/7PZHMKhXsALCx6ijCs2PkuUSr80ikLMNi0SkOu/U KLDZzTEFDxhVrCuxQvQHtraknDC4+s2nXoPs9gyfj3Qwi/wrN5NmywrceCOHUHae5v Dsoqs7MEP7uRbtNaoxOMmHkUPwg4ZdzjpN8kPMVUS9Gld/RrZN3LFL022gBbjsyP2G ve5NtvfScfNpxApm9i4hSCvpxafIiNnGXAmh9TWcRASLB34B9FXcofda3rC1lPtf2F 74zpY40sF2KLwEm9dQrh2I+rHRh/dVDpJ5qsWJumQjWnkyLB4t7bZru5huzWMQspRT ZEQkrIfXACPAA== Date: Sat, 17 Jul 2021 14:52:48 -0500 (CDT) From: Ariadne Conill To: musl@lists.openwall.com cc: Timo Teras In-Reply-To: <20210717160936.GH13220@brightrain.aerifal.cx> Message-ID: <7aebea1d-b662-75c4-14cb-b614ff1aac9f@dereferenced.org> References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> <20210717132543.GG13220@brightrain.aerifal.cx> <20210717184010.246e7895@vostro> <20210717160936.GH13220@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [musl] 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 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