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.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7604 invoked from network); 3 Apr 2023 16:14:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 Apr 2023 16:14:19 -0000 Received: (qmail 28633 invoked by uid 550); 3 Apr 2023 16:14:17 -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 28599 invoked from network); 3 Apr 2023 16:14:16 -0000 Date: Mon, 3 Apr 2023 18:14:03 +0200 From: Szabolcs Nagy To: Matt Wozniski Cc: musl@lists.openwall.com Message-ID: <20230403161403.GI3630668@port70.net> Mail-Followup-To: Matt Wozniski , musl@lists.openwall.com References: <20230331114009.GF3630668@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [musl] Unwinding multithreaded musl applications with elfutils fails * Matt Wozniski [2023-04-01 22:57:09 -0400]: > On Fri, Mar 31, 2023 at 7:40=E2=80=AFAM Szabolcs Nagy wr= ote: > > > > * Matt Wozniski [2023-03-30 22:43:28 -0400]: > > > Using the elfutils eu-stack program or libdw's dwfl_getthread_frames > > > API to unwind multithreaded applications linked against musl libc on > > > x86-64 fails, getting stuck on `__clone`: > > > > musl has limited cfi debug info support (target specific), likely the > > unwinder needs a > > > > .cfi_undefined rip > > > > in the clone start function to know where the stack frames end. > ... > > musl supports building things without any cfi debug info since c > > does not require unwind support, but linux systems nowadays assume > > unwind tables are part of the platform abi so musl based distros > > should probably include it. > ... > > musl does not guarantee frame-pointers either >=20 > So, if I understand what you're saying correctly: musl itself doesn't > guarantee the ability to unwind through it at all (neither using DWARF > unwind tables nor using frame pointers), but musl based distros like > Alpine ought to include proper unwind tables. Does that mean that you > don't consider the lack of CFI for `__clone` a defect in musl, but > that it's still worth reporting to the Alpine musl maintainers as a > defect in Alpine's musl build? >=20 > If so, what would distro maintainers have to do in order to remedy > that defect? Would it be patches to the (target specific) `clone.s` to > add appropriate CFI when building musl for the distro? musl has no cfi annotation by default, but there is a tool that adds it to asm on some targets and the compiler can generate cfi for c code. i think distros should enable cfi when building musl (currently it is only in debug builds i think). but it seems this is not enough to mark the end of the stack frames. > > (it could figure out the end with the same heuristic that gdb uses, > > but apparently elfutils is not smart enough). > > > > some backtracers may want cleared frame-pointer (rbp=3D0) to detect > > the end. > ... > > rbp=3D0 may be the reason why backtrace in the main thread works, so it > > may be enough to do that in threads too. >=20 > And it sounds like both of these are workarounds that elfutils might > be able to pursue in the absence of correct unwind information built > into musl itself. Thanks, that gives a useful direction to dig in. it seems __clone already has xor %ebp,%ebp maybe we need a rule in add-cfi.x86_64.awk to emit cfi based on that.