Date: Fri, 04 Jul 1997 11:44:50 +0000
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: GNU assembler
To: Cesar Scarpini Rabak <csrabak AT dce03 DOT ipt DOT br>
Cc: Nate Eldredge <eldredge AT ap DOT net>, dov AT israel DOT sun DOT com, djgpp AT delorie DOT com
Reply-to: billc AT blackmagic DOT tait DOT co DOT nz
Message-id: <33BCE232.3344@blackmagic.tait.co.nz>
Organization: Tait Electronics NZ
MIME-version: 1.0
Content-type: multipart/mixed; boundary="------------11AF582013AD"
References: <1 DOT 5 DOT 4 DOT 32 DOT 19970703212818 DOT 006a23b8 AT dce03 DOT ipt DOT br>
Precedence: bulk

This is a multi-part message in MIME format.

--------------11AF582013AD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Cesar Scarpini Rabak wrote:
> 
> At 10:42 03/07/97 -0700, Nate Eldredge wrote:
> >GAS is sort of ugly and buggy for writing assembly routines. I recommend
>                          ^^^^^
> What bugs have you noticed in it?

This one for which the patch to gas is attached (to be in the next
release).

Bill

--------------11AF582013AD
Content-Type: text/plain; charset=us-ascii; name="gas.pat"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="gas.pat"

From - Fri Jul 04 08:14:23 1997
Return-Path: <ian AT cygnus DOT com>
Received: from teleng1.tait.co.nz gatekeeper.tait.co.nz by blackmagic.tait.co.nz (SMI-8.6/SMI-SVR4)
	id EAA15985; Thu, 3 Jul 1997 04:09:19 +1200
Received: from tweedledumb.cygnus.com by teleng1.tait.co.nz gatekeeper.tait.co.nz (SMI-8.6/SMI-SVR4)
	id EAA13997; Thu, 3 Jul 1997 04:15:13 +1200
Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id MAA27988
	for <billc AT blackmagic DOT tait DOT co DOT nz>; Wed, 2 Jul 1997 12:06:48 -0400 (EDT)
Received: (ian AT localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id MAA13035; Wed, 2 Jul 1997 12:06:48 -0400
Date: Wed, 2 Jul 1997 12:06:48 -0400
Message-Id: <199707021606 DOT MAA13035 AT subrogation DOT cygnus DOT com>
To: billc AT blackmagic DOT tait DOT co DOT nz
In-reply-to: <33BA3AE5 DOT 2EAB AT blackmagic DOT tait DOT co DOT nz> (message from Bill Currie
	on Wed, 02 Jul 1997 11:26:29 +0000)
Subject: Re: binutils 2.7 coff bug(?) with non-standard sections
From: Ian Lance Taylor <ian AT cygnus DOT com>
X-UIDL: e66be0d72db2cac890105932e1f0ad2e
X-Mozilla-Status: 0011
Content-Length: 1839

   Date: Wed, 02 Jul 1997 11:26:29 +0000
   From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>

   There seems to be a bug somewhere in binutils (BFD?) with coff files
   that have non-standard code sections.

I agree.  I think the only case where this can arise is a call
instruction to a symbol in the same segment.  This patch appears to
fix the bug.  It will be in the next release.

Thanks for the bug report.

Ian Taylor
ian AT cygnus DOT com

Index: config/obj-coff.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gas/config/obj-coff.c,v
retrieving revision 1.144
diff -u -r1.144 obj-coff.c
--- obj-coff.c	1997/05/21 21:40:23	1.144
+++ obj-coff.c	1997/07/02 16:04:55
@@ -4052,11 +4052,21 @@
 
 	      add_number += S_GET_VALUE (add_symbolP);
 	      add_number -= md_pcrel_from (fixP);
-#if defined (TC_I386) || defined (TE_LYNX)
-	      /* On the 386 we must adjust by the segment vaddr as
-		 well.  Ian Taylor.  */
-	      add_number -= segP->scnhdr.s_vaddr;
-#endif
+
+	      /* We used to do
+		   add_number -= segP->scnhdr.s_vaddr;
+		 if defined (TC_I386) || defined (TE_LYNX).  I now
+		 think that was an error propagated from the case when
+		 we are going to emit the relocation.  If we are not
+		 going to emit the relocation, then we just want to
+		 set add_number to the difference between the symbols.
+		 This is a case that would only arise when there is a
+		 PC relative reference from a section other than .text
+		 to a symbol defined in the same section, and the
+		 reference is not relaxed.  Since jump instructions on
+		 the i386 are relaxed, this could only arise with a
+		 call instruction.  */
+
 	      pcrel = 0;	/* Lie. Don't want further pcrel processing. */
 	      if (!TC_FORCE_RELOCATION (fixP))
 		{


--------------11AF582013AD--