From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126584 invoked by alias); 25 Jan 2016 16:01:12 -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 126570 invoked by uid 89); 25 Jan 2016 16:01:11 -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= 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 25 Jan 2016 16:01:10 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id BF6B18E39E; Mon, 25 Jan 2016 16:01:09 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-93.ams2.redhat.com [10.36.116.93]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0PG167J020105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Jan 2016 11:01:08 -0500 Date: Mon, 25 Jan 2016 16:01:00 -0000 From: Jan Kratochvil To: Bogdan Harjoc Cc: gdb@sourceware.org Subject: Re: Adding a missing NT_FILES note to a core file so gdb can load solibs for it Message-ID: <20160125160106.GA9386@host1.jankratochvil.net> References: <20160125142226.GA5665@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00053.txt.bz2 On Mon, 25 Jan 2016 16:56:53 +0100, Bogdan Harjoc wrote: > because read_memory...() reads 0x0 from info->debug_base + lmo->r_map_offset. > > What I can't figure out is where the rld map should be in the core file. This is usually because I said that most commonly the executable does not match the one from the core file. And therefore that computed address is bogus and statistically memory contains most probably zeroes which is what you see, the zero. Jan