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 8583 invoked from network); 17 Jul 2021 10:38:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2021 10:38:43 -0000 Received: (qmail 9535 invoked by uid 550); 17 Jul 2021 10:38:40 -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 9517 invoked from network); 17 Jul 2021 10:38:39 -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=AUb25xs9e4eSSgJGqtmq4ZVQEFWuYbdMcjICbQ3LAss=; b=U/mFBmYCoADFAMeE5B+vnTVfrTlzC9v2fKANM4zLcn5l+dvCP+5P6KJMx1GiS+/zGp mWRrkfLECDfE7kh8/1rOlCu1By8CtAEPveiUnRNySzd2KL+ig7f7Ae2shgBUCBup/0ik qXEnBaAdwWdKj+UYmrCaDlbZGkQusMri6wjysTdpEZ0rN7vb2i4iOl9ZQP8O/2cLW+A4 AXFuke+ZwioxpZDDSaqvfWq7jwZsdpADaREpPCNUByZ2rrAmGd9Kf1biY7zbm7Pm2NUe 5kyun4PVO3txMKAz4On9MMu+M0X2Obqv3rfjlAlAxqEJnpMPDMwEmNZuTvrg7G0dcfnt qziQ== X-Gm-Message-State: AOAM533DAH/KzJdVJEv5GoYhBHcYq1WhU/wGA3b7OilJsGLsZudk/Toj AYb1capiWZklDgGAvC4SaXATX8hI73k= X-Google-Smtp-Source: ABdhPJydQsDQTu6lTjKDhww7blBj4EmiK+HaWSrD9JFcHNFOTjce2nNkdW5wyr+lFkhosRBWuXW/+w== X-Received: by 2002:a19:6452:: with SMTP id b18mr11412290lfj.545.1626518308635; Sat, 17 Jul 2021 03:38:28 -0700 (PDT) Date: Sat, 17 Jul 2021 13:38:25 +0300 From: Timo Teras To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20210717133825.07eae84e@vostro> In-Reply-To: <20210717103338.3085f754@vostro> References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> 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 10:33:38 +0300 Timo Teras wrote: > On Fri, 16 Jul 2021 11:57:35 -0400 > Rich Felker wrote: > > > You can solve this problem just as well for the things you want to > > have work by including the (part of) the debug info you want in the > > main libc.so binary: .debug_frame. > > For me it's quite unusual to have .debug_frame but not other debug > sections. I assume it works. But the tooling certain does not endorse > this setup. I suppose it can be achieved with some objcopy magic, but > requires care. I'm investigating this. And seems that "strip -g --keep-section=.debug_frame" works after all. I remember objcopy often not doing what wanted, but happily this is doable in a simple enough way. However, there actually is some reasons why .eh_frame that goes to LOAD phdr is helpful. That is core dump (when all of the mapped memory is dumped). This allows easy investigation of crashed program state with proper tooling even if none of the debug info is available. .debug_info would not go there because it's not mapped. Granted, the above is a bit of rare condition and probably not of huge importance for many. But I do use it regularly. Another difference is that there's no .eh_frame_hdr equivalent which allows binary searchable tree based on PC. But then again, this is mostly useful for backtrace() style usage. External stuff like debuggers and profilers etc. can build this runtime if needed - it just is a small (hopefully onetime) extra performance hit. I think just keeping .debug_frame would solve the problems I'm having (modulo the core dump case). But since the backtrace() and other things are also involved, I hope we could have a proper discussion on the technical side. And also consider if "the badness" could be made "bad" (by crashing or similar) even if including .eh_frame. Speaking of this, I'm wondering how many C-library functions can call callbacks? Another approach would be to arm these functions with __attribute__((cleanup())) where the clean up crashes if called via unwind. Probably bad idea extra work wise, but would make it very obvious unconditionally that unwinding C-functions is not wanted. Makes one hope gcc had a way to insert personality function to crash on unwind attempt... Also, what if the code base is compiled with frame-pointers enabled? Does that make unwinding work even without eh_frame? Is the "-fomit-frame-pointer" vs. "-fno-omit-frame-pointer" affecting current perceived "contract"? Timo