From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16056 invoked by alias); 8 Nov 2011 01:49:30 -0000 Received: (qmail 16045 invoked by uid 22791); 8 Nov 2011 01:49:29 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Nov 2011 01:49:02 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA81n1tN029375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Nov 2011 20:49:01 -0500 Received: from psique (ovpn-112-51.phx2.redhat.com [10.3.112.51]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA81mts7025847; Mon, 7 Nov 2011 20:48:58 -0500 From: Sergio Durigan Junior To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Implement new `info core mappings' command References: <20111031001117.GA11608@host1.jankratochvil.net> <20111031070012.GA32610@host1.jankratochvil.net> <20111104162648.GA30571@host1.jankratochvil.net> Date: Tue, 08 Nov 2011 01:49:00 -0000 In-Reply-To: <20111104162648.GA30571@host1.jankratochvil.net> (Jan Kratochvil's message of "Fri, 4 Nov 2011 17:26:48 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00167.txt.bz2 Hello, Thanks for the review. I am still working on the patch, but I have a question. Jan Kratochvil writes: > On Thu, 03 Nov 2011 21:00:39 +0100, Sergio Durigan Junior wrote: >> + { >> + filename = s->objfile->name; >> + break; >> + } > > I think the logic should be opposite. Not to find any part of the core > segment from some file but ensure the whole segment is mapped from that file. > > For ELF core files you should rather check also the ELF segments in > objfiles->obfd and verify it is fully covered. (I said off-list something > different, not seeing the code, sorry.) That is verify every byte between > 0x37aa200000 and 0x37aa222000 belongs to any of the segments from such file. > Otherwise you may print a filename for some core file segment while only part > of that segment is from that file (it probably will not happen for normal core > files but GDB is for debugging problems so it should never give inexact > results). This one is giving me headaches... When I implemented the algorithm, some objfiles were supressed. Anyway, I'm still working on it (and that's not the question I wanted to ask). >> + >> + if (bitness == 32) >> + printf_filtered ("\t%#10lx %#10lx %#10x %7s\n", >> + start, >> + end, >> + (int) size, >> + filename ? filename : ""); > > Could you print all the info readelf -Wa prints? I would use rather readelf > to see the protection bits, also I guess the file size vs. mem size may > suggest if it is a data segment or code segment, up to you how to display it, > even some indicator "from core file" (memsize==filesize) vs. "from local file" > (filesize==0) vs. "partial" (others, e.g. filesize==0x1000) could be > enough. When you say "all the info", what do you mean? I am not sure I understood your sentence above. Thanks.