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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11305 invoked from network); 29 Jul 2023 05:25:45 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jul 2023 05:25:45 -0000 Received: (qmail 18007 invoked by uid 550); 29 Jul 2023 05:25:42 -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 17963 invoked from network); 29 Jul 2023 05:25:40 -0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ayaya.dev; s=key1; t=1690608328; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tsck70fd+h/lfqCVLmHx+840cGI9eFwDUqUsVQkA5So=; b=wMnKWpVWutLino8XcEpJx1/a+zPA3dWsn+0i33ddaUlGAbTdR09VTgDSgfFStx9mztfHsD pbg26PwslpM2EwKUKuKB6KzxgUtSzSxnTegbamxMkSbD1HmyAwf48DjPqMGp4dv9bEO/Sp 2qICJZ4MdqHd9TNi7R6ezsG1UHY0FsQ= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 29 Jul 2023 05:25:25 +0000 Message-Id: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "alice" To: References: <6CAFA15F-FF1C-4343-8D7F-00A44A815CEA@apple.com> In-Reply-To: <6CAFA15F-FF1C-4343-8D7F-00A44A815CEA@apple.com> X-Migadu-Flow: FLOW_OUT Subject: Re: [musl] [PATCH] Add options to configure script to control frame pointer omission and EH unwind information On Fri Jul 28, 2023 at 11:13 AM UTC, Alastair Houghton wrote: > Hi there, > > Musl currently disables frame pointers and (except in debug builds) also > disables the emission of EH unwind information, the latter presumably in = an > effort to save space. The downside of doing both of these things is that = it > makes it impossible for code to generate reasonable run-time backtraces, = since > without frame pointers the only way to do a stack walk is the EH unwind d= ata, > which has been removed. > > These defaults are probably fine for most people, but not everybody wants= to > build in this configuration, and it would be better to offer some reasona= ble > options here, I think. I attach a patch that adds options to the configur= e > script that allow users of Musl to choose > > * Whether to include frame pointers. > * Whether to include EH unwind tables, and if so whether they should supp= ort > asynchronous unwind or not (asynchronous unwind generates more data in = the > tables, since the compiler isn=E2=80=99t allowed to make assumptions ab= out which code > could throw). > > Note that the existing comment in the configure script about the DWARF ta= bles > is slightly misleading; the options the configure script uses are to do w= ith > EH unwind data (which is for exception handling, in languages that suppor= t it, > as well as for runtime backtracing), and not with DWARF unwind data. The= two > do potentially share some sections and the EH data is stored using DWARF = as a > format, but it *isn=E2=80=99t* debug information - it=E2=80=99s there for= language runtime and > library use. i believe the proposed change, and the rationale for it, had already been thoroughly discussed and rejected in https://www.openwall.com/lists/musl/2021/07/16/1 (not exactly the same, and the above isn't as fine grained, but the core of= it is identical) the core of it is really in (quoting Rich): > The debugger already can do debugging/unwinding because it has access > to the debug information (if you've installed it) and there is a > clear, understood-by-users contract that this information is not an > inherent part of the program but something optional for external > debugging tools only. >> - libunwind/libexecinfo will start to work and give meaningful backtrac= es > > This is explicitly a reason not to. backtrace() considered harmful. there is no intent to allow 'runtime use' of this data (i.e. allow backtrac= es), outside of what already works with an external debugger. unrelatedly (to the prior rejection), i believe these days there has been w= ork on the SFrame format (as opposed to EH), to allow easier backtracing (they aren't mutually exclusive). maybe that is better to build on these days? > > Kind regards, > > Alastair. >