From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29563 invoked by alias); 19 Mar 2019 15:25:51 -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 29545 invoked by uid 89); 19 Mar 2019 15:25:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=BAYES_20,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=Various, jankratochvilredhatcom, kratochvil, sk:jankra 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 15:25:47 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6Gcb-0006gX-Le for gdb@sourceware.org; Tue, 19 Mar 2019 11:25:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59001) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h6Gca-00081u-Fz for gdb@gnu.org; Tue, 19 Mar 2019 11:25:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6GcX-0006XI-NC for gdb@gnu.org; Tue, 19 Mar 2019 11:25:44 -0400 Received: from mail-it1-x12a.google.com ([2607:f8b0:4864:20::12a]:39415) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6GcX-0006Vq-8I for gdb@gnu.org; Tue, 19 Mar 2019 11:25:41 -0400 Received: by mail-it1-x12a.google.com with SMTP id 139so2719520ita.4 for ; Tue, 19 Mar 2019 08:25:41 -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=j934bcyaObDCzBaXaELArO96f99iAWHJJGzUo8mJ164=; b=NpEXR/Er73Q/62uoVAVmlz0dpgoGeSOWYO/sYql7LUOa4vo96+xtkOXmgunrQb+vtf 1ajoYJRVvd6om9rIcOPTEIzgLNscWNY8VVoVFosBp2GCgq6HYDCxVOJ3eOsJS8HM08kw dcXClrwQiyJBQ0D2W6O3OwBPs7zGk6xjixVzQiU+kiijjQ/q1W8abR2cVOBZ02AKE3pt MbXGa6MiVHn5xvV9Ve7cSOwiDprLBr9GpqZ02TkWgv+mjarSh+XTr5WFYPUB8cyc5TVf ngBPHaNCtbT9kWbli/WS/9ioBP/olXmOF5rveB4b9sDo17g9It7XKtYbX/G4ilzAq76u 8b1g== MIME-Version: 1.0 References: <20190314214555.GA2221061@host1.jankratochvil.net> <20190319143542.GA3498328@host1.jankratochvil.net> In-Reply-To: <20190319143542.GA3498328@host1.jankratochvil.net> From: =?UTF-8?Q?Jirka_Koutn=C3=BD?= Date: Tue, 19 Mar 2019 15: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::12a 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/msg00054.txt.bz2 I see, just to make sure - DT_DEBUG gets dumped into the corefile, is that correct? Den tir. 19. mar. 2019 kl. 14:35 skrev Jan Kratochvil < jan.kratochvil@redhat.com>: > On Tue, 19 Mar 2019 15:25:15 +0100, Jirka Koutn=C3=BD wrote: > > PT_NOTE can't be read by gdb, > > Various PT_NOTESs are read by GDB but not PT_NOTE of type NT_FILE. > > > > That being said, how about dlopen()? > > That does not matter, both initially-loaded libraries and dlopen()ed > libraries > are present in DT_DEBUG/_r_debug/r_debug the same way. > > "initially-loaded library" (which is linked automatically, during > compilation > specified by -lNAME) are present in DT_NEEDED but that is for ld.so > (/lib64/ld-linux-x86-64.so.2) and GDB does not care about those. > It would be nice if GDB did but that is an unrelated RFE: > RFE: preload DT_NEEDED library list > https://sourceware.org/bugzilla/show_bug.cgi?id=3D12249 > > > > For what I found out about DT_DEBUG this section gets initialized by ld > as > > by ld.so (/lib64/ld-linux-x86-64.so.2), not /usr/bin/ld. > > > > you said. Do I understand you correctly, this is an alternative to the > > first option, that in fact doesn't require the executable? > > yes, sort of alternative. But NT_FILE is generated by kernel so there can > appear even shared libraries mmap()ed as data files while in > DT_DEBUG/_r_debug/r_debug can be found only libraries really opened by > DT_NEEDED or dlopen()ed. So there is a subtle difference what those two > sources of information mean. > > Also NT_FILE is generated only by Linux kernel (or GDB) while > DT_DEBUG/_r_debug/r_debug are present even on non-Linux UNIXes > (if one thinks there still exist some). > > > Jan >