From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12602 invoked by alias); 21 Nov 2002 04:50:05 -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 12576 invoked from network); 21 Nov 2002 04:50:01 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Nov 2002 04:50:01 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18ElA0-0006Zn-00; Thu, 21 Nov 2002 00:50:00 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18EjHY-0005Q3-00; Wed, 20 Nov 2002 23:49:40 -0500 Date: Wed, 20 Nov 2002 20:50:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Steven Johnson , gdb@sources.redhat.com, binutils@sources.redhat.com Subject: DWARF-2 + discarded link-once sections (was Re: Internal error in GDB) Message-ID: <20021121044940.GA20705@nevyn.them.org> Mail-Followup-To: Jim Blandy , Steven Johnson , gdb@sources.redhat.com, binutils@sources.redhat.com References: <3DD351ED.7000409@neurizon.net> <20021114151528.GA14693@nevyn.them.org> <20021119201044.GA29274@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00301.txt.bz2 On Wed, Nov 20, 2002 at 11:25:26PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > > On Thu, Nov 14, 2002 at 10:15:28AM -0500, Daniel Jacobowitz wrote: > > > On Thu, Nov 14, 2002 at 05:34:05PM +1000, Steven Johnson wrote: > > > > Im getting the error: > > > > > > > > Internal error: pc 0x0 in read in psymtab, but not in symtab. > > > > > > > > from a very recent CVS build of GDB (As of 11th November). > > > > > > > > It happens when I set breakpoints in an assembler file, that has been > > > > assembled through GCC, using the C Preprocessor (.S file, not .s file). > > > > > > > > It does nothing wrong, except pop up all the time and hence interfere > > > > with debugging significantly. (Im using insight and have to keep > > > > pressing OK to continue). > > > > > > > > I searched the code and it seems to be coming from > > > > symtab.c:find_pc_sect_symtab (last if in the function) > > > > Jim, I need your opinion on this... here's the problem. > > > > 2092 /* When using the GNU linker, .gnu.linkonce. sections are used to > > 2093 eliminate duplicate copies of functions and vtables and such. > > 2094 The linker will arbitrarily choose one and discard the others. > > 2095 The AT_*_pc values for such functions refer to local labels in > > 2096 these sections. If the section from that file was discarded, the > > 2097 labels are not in the output, so the relocs get a value of 0. > > 2098 If this is a discarded function, mark the pc bounds as invalid, > > 2099 so that GDB will ignore it. */ > > 2100 if (low == 0 && (bfd_get_file_flags (objfile->obfd) & HAS_RELOC) == 0) > > (top-gdb) > > 2101 return 0; > > 2102 > > > > > > In Steven's asm is a .vectors section which goes over the PPC hardware > > interrupt vectors in RAM - that's actually at VMA 0. Oops. > > > > Since LD still doesn't edit DWARF-2 sections when discarding, and won't > > for the forseeable future (although it needs to eventually), we can't > > just drop the check. Any ideas on what to do? > > Jeez. You'd think we would have learned by now that people like to > put things at the top and bottom of the address space... > > Would it work to check that both the high and low bounds are zero? > Obviously, that's not going to handle a zero-length section at address > zero, but it'd at least be better than what we have now. Nope. The missing section base will be considered to be zero. Thus the size of the discarded section will be whatever it normally would have been, at 0 and 0+size. Isn't it gross? > Is there *no* other way to tell whether the debug info refers to a > discarded section? Can we add logic to BFD to tell us about this? There really isn't. It would be nice to discard it at link time. But this is, well, really complicated. In my inexpert opinion at least. (This is a similar problem to coalesced symbols in Darwin, as I understand it?) Hmm, maybe it isn't as bad as all that for DWARF-2. If we get a die with low_pc and high_pc attributes referring to a discarded section, we could discard the die and all its children. But there might be _references_ to that die somewhere... this requires general purpose DWARF-2 editing that we don't really have yet. I'm CC'ing this over to binutils, because Alan and/or Jakub would have a much better feel for whether this is possible than I do. > Could we generate custom GNU Dwarf 2 information so as to allow GDB to > detect a removed section? That is, if we *ask* the linker to tell us, > will it? We could make all debug info in linkonce sections children > of new DW_TAG_GNU_linkonce dies, with magic attributes that let us > detect whether they've been discarded. This could work too but it would be nice to avoid it. We were discussing .debug_info.gnu.linkonce.* sections at one point; did we abandon that idea because there were too many of them, or was there some other problem? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer