From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87595 invoked by alias); 14 Mar 2019 21:51:47 -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 87569 invoked by uid 89); 14 Mar 2019 21:51:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=jirka, Jirka, executable's, Koutn X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Mar 2019 21:51:46 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4YGO-00084g-Hz for gdb@sourceware.org; Thu, 14 Mar 2019 17:51:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37946) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h4YGO-0002Yt-16 for gdb@gnu.org; Thu, 14 Mar 2019 17:51:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4YGN-000841-5m for gdb@gnu.org; Thu, 14 Mar 2019 17:51:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35230) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h4YGM-00082j-Rd for gdb@gnu.org; Thu, 14 Mar 2019 17:51:43 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1A059CAA6F; Thu, 14 Mar 2019 21:45:59 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 353DE19C56; Thu, 14 Mar 2019 21:45:58 +0000 (UTC) Date: Thu, 14 Mar 2019 21:51:00 -0000 From: Jan Kratochvil To: Jirka =?utf-8?Q?Koutn=C3=BD?= Cc: gdb@gnu.org Subject: Re: question about why gdb needs executable's binary Message-ID: <20190314214555.GA2221061@host1.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-SW-Source: 2019-03/txt/msg00033.txt.bz2 On Wed, 13 Mar 2019 15:24:50 +0100, Jirka Koutn=C3=BD wrote: > I was wondering why does gdb still need the executable's binary as well? > Is there some additional information retrieved from the executable? Yes, without the main executable GDB cannot find the list of shared librari= es. > PT_NOTE contains address ranges and shared libraries names as well, NT_FILE is a recent feature and GDB can only produce it, GDB cannot read it. GDB also cannot read /proc/PID/maps to recognize the list of shared librari= es. > What is the missing bit of information there? To find the list of mapped shared libraries GDB needs to read DT_DEBUG which is located in DYNAMIC segment of the main executable. GDB can read also "_r_debug" but for that it needs to know ld.so which is a mapped shared library so that is a chicked-and-egg problem. eu-stack can do these: With main executable: $ eu-stack --core=3Dsleep.core PID 1886638 - core TID 1886638: #0 0x00007f37e04707f8 __nanosleep #1 0x000055a9557f28d7 rpl_nanosleep #2 0x000055a9557f26b0 xnanosleep #3 0x000055a9557ef7c8 main #4 0x00007f37e03cb413 __libc_start_main #5 0x000055a9557ef89e _start Without main executable: $ eu-stack --core=3Dsleep.core2 PID 1886638 - core TID 1886638: #0 0x00007f37e04707f8 __nanosleep #1 0x000055a9557f28d7 eu-stack: dwfl_thread_getframes tid 1886638 at 0x55a9557f28d6 in /usr/bin/s= leep: Callback returned failure Just that eu-stack does not contain heuristics for unwinding frames with missing unwind information (.eh_frame/.debug_frame) and so if a frame is generated from the main executable it gives up for further unwinding. Jan