From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26343 invoked by alias); 24 Sep 2004 00:18:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26323 invoked from network); 24 Sep 2004 00:17:59 -0000 Received: from unknown (HELO gizmo05bw.bigpond.com) (144.140.70.40) by sourceware.org with SMTP; 24 Sep 2004 00:17:59 -0000 Received: (qmail 11635 invoked from network); 24 Sep 2004 00:17:58 -0000 Received: from unknown (HELO bwmam06.bigpond.com) (144.135.24.84) by gizmo05bw.bigpond.com with SMTP; 24 Sep 2004 00:17:58 -0000 Received: from cpe-144-136-177-39.sa.bigpond.net.au ([144.136.177.39]) by bwmam06.bigpond.com(MAM REL_3_4_2a 53/2601169) with SMTP id 2601169; Fri, 24 Sep 2004 10:17:58 +1000 Received: by bubble.modra.org (Postfix, from userid 500) id A59F3F8722; Fri, 24 Sep 2004 09:47:57 +0930 Date: Fri, 24 Sep 2004 00:18:00 -0000 From: Alan Modra To: Mark Kettenis Cc: bintuils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: elf.c assign_file_positions_for_segments Message-ID: <20040924001757.GF30257@bubble.modra.org> References: <200409231551.i8NFpHkJ025812@juw15.nfra.nl> <20040923234221.GE30257@bubble.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040923234221.GE30257@bubble.modra.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00209.txt.bz2 On Fri, Sep 24, 2004 at 09:12:22AM +0930, Alan Modra wrote: > On Thu, Sep 23, 2004 at 05:51:17PM +0200, Mark Kettenis wrote: > > I'm not sure where to fix this. > > I didn't think about gdb using bfd to generate core files. Clearly, I > need to fix my breakage of assign_file_positions_for_segments. While waiting for gdb to build, I took a look at gcore.c. For read-only sections, I see you clear SEC_LOAD but leave SEC_HAS_CONTENTS set. This is very likely why you're getting filesz non-zero for these sections. The new code consistently checks both SEC_LOAD and SEC_HAS_CONTENTS whereas the old code just checked SEC_HAS_CONTENTS in one place. I'll take a good look at exactly why the SEC_HAS_CONTENTS check is needed, ie. whether the following comment reflects current reality. /* We check SEC_HAS_CONTENTS here because if NOLOAD is used in a linker script we may have a section with SEC_LOAD clear but which is supposed to have contents. */ If we really don't need the SEC_HAS_CONTENTS test, then I'll take it out and gdb gcore should be OK, otherwise I might ask you to clear SEC_HAS_CONTENTS in gdb. -- Alan Modra IBM OzLabs - Linux Technology Centre