From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23992 invoked by alias); 1 Mar 2005 10:50:14 -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 23869 invoked from network); 1 Mar 2005 10:49:53 -0000 Received: from unknown (HELO imta09sl.mx.bigpond.com) (144.140.92.194) by sourceware.org with SMTP; 1 Mar 2005 10:49:53 -0000 Received: from modra.org ([144.136.221.26]) by imta09sl.mx.bigpond.com with ESMTP id <20050301104949.LCFR24140.imta09sl.mx.bigpond.com@modra.org> for ; Tue, 1 Mar 2005 10:49:49 +0000 Received: by bubble.modra.org (Postfix, from userid 500) id 6E9DD19F672; Tue, 1 Mar 2005 21:19:49 +1030 (CST) Date: Tue, 01 Mar 2005 10:50:00 -0000 From: Alan Modra To: binutils@sources.redhat.com Subject: Re: compiling binutils with -DDEBUG Message-ID: <20050301104949.GN5299@bubble.modra.org> Mail-Followup-To: binutils@sources.redhat.com References: <20050301020120.GJ5299@bubble.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2005-03/txt/msg00014.txt.bz2 On Mon, Feb 28, 2005 at 09:36:00PM -0500, Ian Lance Taylor wrote: > Alan Modra writes: > > > (fixup_segment): Remove assertion. > > Didn't seem worth including struct-symbol.h just for this. I suspect > > the assertion isn't true too, since a similar assertion in obj-coff.c > > fails with X_op an O_constant. Maybe this is a real bug. Ian, you're > > probably the only one who can answer mri mode queries off the top of > > your head. Care to comment? > > > @@ -2583,7 +2585,6 @@ fixup_segment (fixS *fixP, segT this_seg > > if (fixP->fx_addsy != NULL > > && symbol_mri_common_p (fixP->fx_addsy)) > > { > > - know (fixP->fx_addsy->sy_value.X_op == O_symbol); > > add_number += S_GET_VALUE (fixP->fx_addsy); > > fixP->fx_offset = add_number; > > fixP->fx_addsy > > The assertion should be true. This is a symbol defined in an MRI > common section. Since we don't generate IEEE object files, we treat > an MRI common section as a single large common symbol. Then we handle > a reloc against a symbol defined within an MRI common section as an > offset to that symbol. The assertion is just checking that we really > do point to the magic symbol we are using for the MRI common section. I did a little analysis. Nowadays, the assertion is always false for BFD_ASSEMBLER because symbols have been resolved (write.c:1857) by the time this code is reached. The following would probably fix the assertion, but I don't think it's worth worrying about. Index: write.c =================================================================== RCS file: /cvs/src/src/gas/write.c,v retrieving revision 1.84 diff -u -p -r1.84 write.c --- write.c 1 Mar 2005 02:00:14 -0000 1.84 +++ write.c 1 Mar 2005 10:46:56 -0000 @@ -1854,7 +1854,8 @@ write_object_file (void) symbolS *symp; for (symp = symbol_rootP; symp; symp = symbol_next (symp)) - resolve_symbol_value (symp); + if (!symbol_mri_common_p (symp)) + resolve_symbol_value (symp); } resolve_local_symbol_values (); -- Alan Modra IBM OzLabs - Linux Technology Centre