From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 907263857C44 for ; Thu, 6 May 2021 00:49:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 907263857C44 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 8D240302BBED; Thu, 6 May 2021 02:49:58 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 46545413CD48; Thu, 6 May 2021 02:49:58 +0200 (CEST) Message-ID: <2425384793cfe2a31e8d4d0c76b36d40f6e5304b.camel@klomp.org> Subject: Re: Missing .gnu_debugdata section on ARM platform when libdw is used by systemd-coredump From: Mark Wielaard To: Tino Mettler , elfutils-devel@sourceware.org Date: Thu, 06 May 2021 02:49:58 +0200 In-Reply-To: <892EDCB7-C2A8-4497-8FF1-986A63EA7F4A@tikei.de> References: <892EDCB7-C2A8-4497-8FF1-986A63EA7F4A@tikei.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 00:50:01 -0000 Hi Tino, On Tue, 2021-05-04 at 14:15 +0200, Tino Mettler via Elfutils-devel wrote: > I have a system running on 2 different architectures: AMD64 and ARM. > When a coredump happens, I want systemd-coredump to generate a stack > trace of the crashing application. Systemd depends on elfutils for > this feature. I use binaries with minidebuginfo (the LZMA compressed > symbol table in the .gnu_debugdata section) on both architectures. >=20 > I get a stack trace on AMD64, but not on ARM. While debugging this, I > saw that find_aux_sym() from dwfl_module_getdwarf.c does not find a > .gnu_debugdata section when iterating through the ELF using > elf_nextscn(). >=20 > However, it finds a .gnu_debuglink section. I inspected the > executable and verified that it contains a .gnu_debugdata section and > it looks fine. Interestingly, there is no .gnu_debuglink section in > the executable despite elf_nextscn() seems to find one. >=20 > It looks like libdw does not process the actual executable, but a > modified variant, and the .gnu_debugdata section gets lost at some > point on my ARM device. Can you give me a hint where I need to look > at? Both devices run a different kernel with a different > configuration. Could that be related? >=20 > I also tried gdb using the coredump file from systemd-coredump and > the same executable, and a stack trace worked as expected. If possible you might want to post the core file and/or executables somewhere so others can inspect them. I am not completely sure how the .gnu_debugdata (aux symbols) is related. Are you getting a backtrace, but not function symbols for the addresses? For ARM it might depend on whether the executable contains an .eh_frame sections. If it has (or the .debug file has an .debug_frame section) then libdw should be able to produce a backtrace. But there are also ARM binaries which only come with IDX data, which libdw doesn't handle. Cheers, Mark