From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22120 invoked by alias); 15 Jun 2006 00:12:21 -0000 Received: (qmail 22112 invoked by uid 22791); 15 Jun 2006 00:12:20 -0000 X-Spam-Check-By: sourceware.org Received: from potter.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Jun 2006 00:12:18 +0000 Received: (qmail 14406 invoked from network); 15 Jun 2006 00:12:16 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jun 2006 00:12:16 -0000 To: Steven Johnson Cc: gdb@sources.redhat.com Subject: Re: Problems with startup code symbols (Copious warnings) References: <4487C21F.2090907@sakuraindustries.com> <44881434.2040207@sakuraindustries.com> From: Jim Blandy Date: Thu, 15 Jun 2006 07:33:00 -0000 In-Reply-To: (Jim Blandy's message of "Wed, 14 Jun 2006 14:44:20 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00086.txt.bz2 Jim Blandy writes: > Steven Johnson writes: >> Will post an app tomorrow that does this, once I've made one. > > I see your post in the archive, but for some reason it didn't reach > me. I'll take a look. Okay. I think I understand part of the problem. If you run 'readelf -wi' on your executable, you should see two DW_TAG_compile_unit entries. Each has DW_AT_high_pc and DW_AT_low_pc attributes. The DWARF data claims that the crt0.c compilation unit covers addresses zero to zero, and that the vectors.S compilation unit covers addresses from zero to 0x104. Then, each of them has a DW_AT_stmt_list that points to line number information, which you can dump with 'readelf -wl'. The crt0.c line number info definitely seems to cover addresses outside the range given in the crt0.c DW_TAG_compile_unit entry. Which is odd. Where did the code from crt0.c really go? Is there some reason relocs against the debugging information aren't getting applied? I didn't quite get everything that was going on in your link line. The other part of the problem is that GDB distrusts DW_AT_low_pc attributes whose values are zero, presuming that they refer to a discarded 'linkonce' section. Here's the code: /* When using the GNU linker, .gnu.linkonce. sections are used to eliminate duplicate copies of functions and vtables and such. The linker will arbitrarily choose one and discard the others. The AT_*_pc values for such functions refer to local labels in these sections. If the section from that file was discarded, the labels are not in the output, so the relocs get a value of 0. If this is a discarded function, mark the pc bounds as invalid, so that GDB will ignore it. */ if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0) return 0; (Linkonce sections are a crock: if a section of code is discarded, the debug info should be discarded along with it, but there's no way to do that with linkonce sections.) But in your case, you really have a compilation unit at address zero. That crock is very important for debugging C++ code. But I don't see any way to distinguish between debug info for a discarded linkonce section and debug info for a CU that is actually linked at address zero. They look the same. But the effect is that GDB creates a symtab structure whose address range is from zero to zero, built from a partial symtab whose address range is from zero to 0x104, which is what produces the warnings: the psymtab promises to cover a given range of code, but when it's expanded into a full symtab, it doesn't. It would be more consistent for GDB to never construct the psymtab in the first place, on the grounds that it looks like debug info for a discarded linkonce section, but that wouldn't help you at all. For now, I think a patch that uses complaints instead of warnings is the best way to get GDB out of your hair. But you're still going to have problems. If anyone can see a way to handle discarded linkonce sections better, I'd love to hear it.