From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2987 invoked by alias); 16 Dec 2009 19:46:55 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2977 invoked by uid 22791); 16 Dec 2009 19:46:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Roland McGrath Cc: Daniel Jacobowitz , archer@sourceware.org Subject: Re: Initial psymtab replacement results References: <20091211235901.GA16889@caradoc.them.org> <20091214230947.GA31362@caradoc.them.org> <20091216030118.A676A1D7@magilla.sf.frob.com> <20091216185721.52CD1D8@magilla.sf.frob.com> Reply-To: Tom Tromey Date: Wed, 16 Dec 2009 19:46:00 -0000 In-Reply-To: <20091216185721.52CD1D8@magilla.sf.frob.com> (Roland McGrath's message of "Wed, 16 Dec 2009 10:57:21 -0800 (PST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00113.txt.bz2 >>>>> "Roland" == Roland McGrath writes: Tom> There's also an issue with knowing whether it is actually complete; I Tom> didn't think of this until relatively recently: Tom> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288 Roland> I think we discussed this before and I've forgotten again why Roland> that issue matters. In the status quo there is a .debug_aranges Roland> hunk for each CU from the beginning of the existing of the Roland> corresponding .debug_info hunk at compile time, and that can Roland> never be "stripped" except by strip et al that remove Roland> .debug_info along with it. Nothing requires a compiler to emit .debug_aranges for a CU. It is an optional index, at least by my reading: [6.1 Accelerated Access] ... a producer of DWARF information may provide... So, if there is no aranges entry for a given CU, there is no way to tell whether the CU has no addressable content, or whether the entry was simply never created. This is not an issue if you are willing to assume that the user is using GCC, because AFAIK (modulo the bug we found) GCC always emits this with -g. GDB aspires to be more defensive, though. So, on my current branch, if GDB notices a missing aranges entry, it reads full symbols for the CU just in case. This triggers a number of times in OO.o. The PR in question is suspended because I told rth that it wasn't clear we would even be using aranges. Overall this is fairly minor. It isn't likely to affect Fedora. I have no idea what, if anything, other gdb maintainers might say about it. Maybe we can just ignore it. This issue affects .debug_pub* as well. Tom