From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127710 invoked by alias); 13 Jul 2017 15:22:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 127701 invoked by uid 89); 13 Jul 2017 15:22:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Ossman, ossman, Pierre, pierre X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jul 2017 15:22:07 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5B467CE1A; Thu, 13 Jul 2017 15:22:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B5B467CE1A Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jan.kratochvil@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B5B467CE1A Received: from host1.jankratochvil.net (ovpn-116-70.ams2.redhat.com [10.36.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F001D17AE6; Thu, 13 Jul 2017 15:22:04 +0000 (UTC) Date: Thu, 13 Jul 2017 15:22:00 -0000 From: Jan Kratochvil To: Pierre Ossman Cc: gdb@sourceware.org Subject: Re: Decoding stack in core file without correct libs? Message-ID: <20170713152202.GA23718@host1.jankratochvil.net> References: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> User-Agent: Mutt/1.8.3 (2017-05-23) X-SW-Source: 2017-07/txt/msg00027.txt.bz2 On Thu, 13 Jul 2017 11:24:50 +0200, Pierre Ossman wrote: > I'd like to see if there is a way to produce binaries so that gdb can walk > the stack in a core dump even if the libraries gdb sees doesn't match the > libraries when the core dump was generated. Features described below are present at least in Fedora (and some of them on RHEL-7). Basic requirement is so-called build-id: $ readelf -n /bin/bash ... Displaying notes found at file offset 0x00000274 with length 0x00000024: Owner Data size Description GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: bad838505c566d846ec9571e4f592d108064cf92 Then Fedora GDB; not upstream GDB - this feature was never reviewed upstream [PATCH v12 00/32] Validate binary before use https://sourceware.org/ml/gdb-patches/2015-08/msg00590.html will guide one to provide the matching packages for it: $ gdb core.21935 ... Missing separate debuginfo for the main executable file Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/07/379f708a44a91477b1407baf59c9bc1426d69e Core was generated by `bc'. ... # dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/07/379f708a44a91477b1407baf59c9bc1426d69e ... Installing : bc-debuginfo-1.06.95-16.fc24.x86_64 1/1 ... $ gdb core.21935 ... Missing separate debuginfos, use: dnf debuginfo-install glibc-2.24-9.fc25.x86_64 readline-6.3-8.fc24.x86_64 ... Installation of such libraries is sure a problem if you run on a system with different libraries - you do not want to replace your system libraries just to make a backtrace. For such case there is ABRT - it will automatically build a new chroot with libraries matching build-ids from the core file. https://developer.fedoraproject.org/tools/abrt/about.html Otherwise one can also try store all the binaries into the core file: (ulimit -c unlimited;echo 0xff >/proc/self/coredump_filter;exec myapp appargs) -> eu-stack --core=core.21760 eu-stack from elfutils can extract debug information from binaries contained in the core file (GDB cannot do that). Although during my experiment it succeeded with the libraries but it still failed to backtrace executable of a different version on disk, there may be some bug. Regular core file backtraced on a different system: $ eu-stack --core=core.21935 PID 21935 - core TID 21935: #0 0x00007f88835d3a80 eu-stack: dwfl_thread_getframes tid 21935 at 0x7f88835d3a80 in /usr/lib64/libc-2.24.so: Callback returned failure coredump_filter-extended core file backtraced on a different system: eu-stack --core=core.21760 PID 21760 - core TID 21760: #0 0x00007ff4ee365a80 __read #1 0x00007ff4eeab4d1d rl_getc #2 0x00007ff4eeab559a rl_read_key #3 0x00007ff4eea9ee32 readline_internal_char #4 0x00007ff4eea9f595 readline #5 0x0000559a6c1ad47c eu-stack: dwfl_thread_getframes tid 21760 at 0x559a6c1ad47b in /usr/bin/bc: Callback returned failure ^^^ some bug, #5 is in /usr/bin/bc which should be present in the core file. Jan