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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3800 invoked from network); 18 Jul 2021 06:09:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jul 2021 06:09:38 -0000 Received: (qmail 22221 invoked by uid 550); 18 Jul 2021 06:09:37 -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 22203 invoked from network); 18 Jul 2021 06:09:36 -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=sKDCG9gaV5W4vEXPj8fnv6qryjBd6u+mZ0IvRlcK9b4=; b=g4e7dUQ6TRG51KcvXo9JtmRrFoewzMu+c3MhSfL1Bb+YBd/xBRtMX4HdS1SG7U42zd 3URIa1awd1OUGw4GS4AwIy3KrBVoZx0lWLaDUU5rte1W0jjFBUKmsH78oWfg3UhCQbLJ vxkwoJQuHpW1o1ovHslwc6/dF7fMENtfJCgA8c6t1Hm3azY2WuYWLYiVL8xQ9pkvpg1Z CDYn3aXy2yhFI6xinpnr0+c5CLehwNvMgHsRNioPKVh1rEIKKKVESVhblrggonFHHMJ1 naWNQUrSkamD+7ufH1ora4N5Q6I/aciKcwMhbQTAcHv24yCnG02kYn0FVixPN7Quw0H9 nKDg== X-Gm-Message-State: AOAM532PoeT9QsT7kmadMbqQcthUwhPYfwxgcTadBoU+LI+lwJhIkMdZ z2umgwFB9IOqhaXz80DhyLw= X-Google-Smtp-Source: ABdhPJzxOOyytzV8ldakt0aQG/YjD9rVCpuKVP0Crx4rZ+xovD3cFLVyTxBmX8S0yIcJ/7erKD2V0w== X-Received: by 2002:a05:651c:b2b:: with SMTP id b43mr3117176ljr.476.1626588565195; Sat, 17 Jul 2021 23:09:25 -0700 (PDT) Date: Sun, 18 Jul 2021 09:09:22 +0300 From: Timo Teras To: Rich Felker Cc: Ariadne Conill , musl@lists.openwall.com Message-ID: <20210718090922.635b96f8@vostro> In-Reply-To: <20210717235635.GI13220@brightrain.aerifal.cx> 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> <7aebea1d-b662-75c4-14cb-b614ff1aac9f@dereferenced.org> <20210717235635.GI13220@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 19:56:36 -0400 Rich Felker wrote: > Having something as part of the loadable program segment means it's > always available, not strippable or missing if debug packages are not > installed. Having it be in a non-load section (not segment) means > it's metadata about the binary for tooling (e.g. debugger) usage, to > be accessed by reading the file(s) not runtime data structures mapped > in memory. From my perspective, the reason for it to be the latter is > to reflect that this is debug info available only in a debug > environment, not part of musl's runtime interfaces. So basically if I understand correctly: 1. You want all musl libraries to have equal (or forward-going) expectation of what is included in the LOAD segments. 2. Even if users expect/rely on debug_frame it's acceptable because that is strippable and shows this is "optional" or "debug" feature. This does makes sense. However, I thought the primary case was the unwinding through C-library and backtrace(). And trying distro to force patch packages instead of having those work. Just noting this because .debug_frame might make us not notice some of the "badness". I do have some technical reasons why I'd prefer .eh_frame (getting it on core dumps). Fortunately I need these from development boxes where I can have custom build for internal use only. So if .debug_frame is needed for peace, then so be it. Though, I still hope to see the time and a way having .eh_frame would acceptable. Is there anything I could implement or do to make it acceptable? For me it's presence is not "contract" commitment because it's not ABI feature. It only affects the functions we have not promised to implement. As explained just keeping .debug_frame is similar "de facto contract" to distro users. The fact whether it's not strippable or not does not matter, what matters is what is being shipped by default. Timo