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.6 required=5.0 tests=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 8387 invoked from network); 17 Jul 2021 15:40:28 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2021 15:40:28 -0000 Received: (qmail 28143 invoked by uid 550); 17 Jul 2021 15:40:26 -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 28125 invoked from network); 17 Jul 2021 15:40:25 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+Kc7+JKiwS+sbfnfYzHlEJP8v76ka2SCen+ai8Yjkpc=; b=YHqqXtKZbOULsuupcVsd4q59Som03NoABWsekB0LxBqnjENCNUvrPyDcus6jwcLW2O ybhmLSiAY+dWh/15LOWT158/uTbZQF66pofEYuQ3vEXbAfbe2P+255barc+4k2xpImfz GdNLyJ7UdKq+DnxQG3R99ChLLb8+dCLwnxY2pVTtaD5Hoa/W4azROlSxkIShd4qKsksk lD3gU6lDWSEU1BP6Ur4pSkhnOTBi9fPgneRHgpRaq3xvY0SPxisns9vrdJ9HU767mQ1t rw6h/DQiEprMfAx45vdvkqHn4crtapNUDTSWw4rWieYUXYgtjKv8rfyAE3mXZqnayXZj K+bg== X-Gm-Message-State: AOAM532g/cWiRn3vtQqAgusdxgl7UbESHdJntlvTFeR08kJX+T9uhpXm 03lLEFp+8VJZVSCBl55+/yEboKsZpCQ= X-Google-Smtp-Source: ABdhPJw7bWDYbCvqP375GMahR78M+dgRg1gqLwSBjD0tXeMwhGzJMpO/bkISUFIBEpyB7DDGO7U+hw== X-Received: by 2002:a05:651c:1798:: with SMTP id bn24mr13825248ljb.335.1626536414358; Sat, 17 Jul 2021 08:40:14 -0700 (PDT) Date: Sat, 17 Jul 2021 18:40:10 +0300 From: Timo Teras To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20210717184010.246e7895@vostro> In-Reply-To: <20210717132543.GG13220@brightrain.aerifal.cx> References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> <20210717132543.GG13220@brightrain.aerifal.cx> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.28; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] option to enable eh_frame 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. > > 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. 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? Timo