Github messages for voidlinux
 help / color / mirror / Atom feed
From: nekopsykose <nekopsykose@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [RFC] libexecinfo broken on musl
Date: Sun, 18 Dec 2022 07:47:12 +0100	[thread overview]
Message-ID: <20221218064712.V5R0ses7DPsIEd0Mnr356msa3Tb8KacVnjfL07ds3GA@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-41159@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356699095

Comment:
> The downside of using this implementation is that the abi is different meaning that all applications using libexecinfo will need to be recompiled.  

the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match.  

> supposedly fixed  

well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)  

> fixing libexecinfo  

this isn't really possible, i don't think. the primary reason is in the linked mailing list discussion- without adding `eh_frame`, it's impossible for the execinfo backtrace to resolve inside the libc. but this sort of low level stuff isn't really something i specialise in, so don't take that as a 100% authoritative statement.  

on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable. i don't remember in what scenarios it returned something non-empty, i'd have to look again.



  reply	other threads:[~2022-12-18  6:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-18  5:23 [ISSUE] " oreo639
2022-12-18  6:47 ` nekopsykose [this message]
2022-12-18  6:47 ` nekopsykose
2022-12-18  6:48 ` nekopsykose
2022-12-18  6:53 ` nekopsykose
2022-12-18  6:54 ` nekopsykose
2022-12-18  6:59 ` nekopsykose
2022-12-18  7:16 ` nekopsykose
2022-12-18  8:41 ` oreo639
2022-12-18  8:43 ` oreo639
2022-12-18  8:43 ` oreo639
2022-12-18  8:44 ` oreo639
2022-12-18  8:45 ` oreo639
2022-12-18  8:45 ` oreo639
2022-12-18  8:48 ` oreo639
2022-12-18  8:49 ` oreo639
2022-12-18  8:50 ` oreo639
2022-12-18  8:53 ` oreo639
2022-12-18  8:54 ` nekopsykose
2022-12-18  8:54 ` oreo639
2022-12-18  8:54 ` nekopsykose
2022-12-18  8:55 ` nekopsykose
2022-12-18  8:55 ` oreo639
2022-12-18  9:41 ` oreo639
2022-12-18  9:49 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:51 ` oreo639
2022-12-18  9:52 ` oreo639
2022-12-18  9:53 ` oreo639
2022-12-18  9:54 ` oreo639
2022-12-18  9:59 ` oreo639
2022-12-18 10:17 ` nekopsykose
2023-03-19  2:02 ` github-actions
2023-03-19  2:18 ` oreo639
2023-03-19  3:06 ` nekopsykose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221218064712.V5R0ses7DPsIEd0Mnr356msa3Tb8KacVnjfL07ds3GA@z \
    --to=nekopsykose@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).