From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121305 invoked by alias); 19 Mar 2019 14:25:33 -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 121296 invoked by uid 89); 19 Mar 2019 14:25:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=sleep, H*RU:f8b0, HX-Spam-Relays-External:f8b0, H*r:gdb@gnu.org 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; Tue, 19 Mar 2019 14:25:30 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6FgH-00014r-3B for gdb@sourceware.org; Tue, 19 Mar 2019 10:25:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41289) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h6FgG-0007Aa-OM for gdb@gnu.org; Tue, 19 Mar 2019 10:25:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6FgF-00013u-FX for gdb@gnu.org; Tue, 19 Mar 2019 10:25:28 -0400 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]:38041) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6FgF-00011T-2Q for gdb@gnu.org; Tue, 19 Mar 2019 10:25:27 -0400 Received: by mail-io1-xd2d.google.com with SMTP id v4so16934902ioj.5 for ; Tue, 19 Mar 2019 07:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TXOdyVvlwFkXrYkUGxqZ7zapOSeBVX6Y1HOt7hCGel8=; b=SJhmxrUhC/L7WJ+VO3Xz3WrAPgUOTeuwUjzxaZy4Ft+yLLCBcKbAkHxPsE0q/6h/zJ zImMEa643ys4NbyCE5rEW/XgU4xHHEi6b1fUuQfm1qhN1F+KTntaJCtQIeg7mSX8uTDh V0PK6pRidj7KcrhfxZ2k291utYcsX/6dWrwH7aOviAHzmMpHLua7YOnZc1THPEASJ97T BOX2TEFfMoBB/9SIlvaSVGIH5oVEkufNOA/G87FGI0Z0AmBLQF0uMv0lC3Ztr3C6uT4G A7JBSAJoth2X5efalImYZesVU3q/FlHeOwNOKcNgoNwlK3+vnDgP9Pez/Lg+CtgxcFu4 iN/A== MIME-Version: 1.0 References: <20190314214555.GA2221061@host1.jankratochvil.net> In-Reply-To: <20190314214555.GA2221061@host1.jankratochvil.net> From: =?UTF-8?Q?Jirka_Koutn=C3=BD?= Date: Tue, 19 Mar 2019 14:25:00 -0000 Message-ID: Subject: Re: question about why gdb needs executable's binary To: Jan Kratochvil Cc: gdb@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2d X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-03/txt/msg00052.txt.bz2 Sorry for the delay, I needed some time to read up on DT_DEBUG and r_debug. It makes a little bit more sense now, so thanks a lot. If you find time, I'd still like to ask a few more questions: PT_NOTE can't be read by gdb, that settles it, thanks *thumb up*. That being said, how about dlopen()? How do these get in the trace? Surely not from the executable. For what I found out about DT_DEBUG this section gets initialized by ld as you said. Do I understand you correctly, this is an alternative to the first option, that in fact doesn't require the executable? Thank you Jirka Den tor. 14. mar. 2019 kl. 21:45 skrev Jan Kratochvil < jan.kratochvil@redhat.com>: > 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 > libraries. > > > > 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 > libraries. > > > > 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/sleep: 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 >