From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31279 invoked by alias); 18 Jul 2002 03:20:08 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 31261 invoked from network); 18 Jul 2002 03:20:06 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sources.redhat.com with SMTP; 18 Jul 2002 03:20:06 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id g6I3K400000496; Wed, 17 Jul 2002 23:20:04 -0400 (EDT) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id g6I3K32m000495; Wed, 17 Jul 2002 23:20:03 -0400 (EDT) Message-Id: <200207180320.g6I3K32m000495@hiauly1.hia.nrc.ca> Subject: Re: SIGSEGV in ld at elflink.h:5500 To: amodra@bigpond.net.au (Alan Modra) Date: Wed, 17 Jul 2002 20:35:00 -0000 From: "John David Anglin" Cc: binutils@sources.redhat.com In-Reply-To: <20020717050239.GW30362@bubble.sa.bigpond.net.au> from "Alan Modra" at Jul 17, 2002 02:32:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00443.txt.bz2 > On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote: > > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem. > > Because elf32_hppa_check_relocs has this code > > if (need_entry & NEED_DYNREL) > { > . > . > if (... > && (sec->flags & SEC_ALLOC) != 0 > > and similarly elsewhere. elf32-hppa doesn't emit dynamic relocs for > debugging sections. I don't think this is the problem. As far as I can tell, we are not emitting dynamic relocs for the debugging sections. If you look back at the original report, you will see that the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section has its output_section set to the bfd_abs_section. It has SEC_ALLOC set in its flags and SEC_EXCLUDE is not set. It has a nonzero size. Thus, the only apparent reason that the output_section for this section is set to the bfd_abs_section is that there are multiple copies of this weak function/section. Looking at the .o source files, there appear to be four input objects containing this weak function. There are a couple of possibilities for the symbol reference that causes the problem. I know that the reloc is local, from the .data section, from io-inst.o. The SEC_ALLOC is set in the flags of the .data section when the symbol is put onto the dynlocal list. We have the following assembly code for for _ZTv0_n24_NSdD1Ev in io-inst.s: .IMPORT _ZTv0_n24_NSdD1Ev,ENTRY .section .gnu.linkonce.t._ZTv0_n24_NSdD1Ev,"ax",@progbits .align 8 .weak _ZTv0_n24_NSdD1Ev .EXPORT _ZTv0_n24_NSdD1Ev,ENTRY L$FB1521 .loc 40 64 0 _ZTv0_n24_NSdD1Ev .PROC .CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3 .ENTRY std %r2,-16(%r30) L$CFI0122 ... The symbol that causes the problem comes from io-inst.o. io-inst.o is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that causes the seg fault. The most likely symbol is a reference to L$FB1521 in the .data section: L$SFDE0073 .word L$EFDE0073-L$ASFDE0073 L$ASFDE0073 .word L$ASFDE0073-L$frame0001 .dword L$FB1521 .dword L$FE1521-L$FB1521 ... This is code is not present without eh information, so we have the link with enabling eh frame information. The above is also consistent with the DIR64 reloc. So, what do we do? We have have a reference in the data section to a local label in a function that has been deleted. On hppa-linux, the above data is in .eh_frame. Is it somehow special? Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)