From raeburn@cygnus.com  Fri Jan  3 17:47:00 1997
From: raeburn@cygnus.com (Ken Raeburn)
Date: Fri, 03 Jan 1997 17:47:00 -0000
Subject: snapshot status
Message-ID: <9701040147.AA31724@cujo.cygnus.com>

Due to some recent firewall changes at Cygnus, the snapshots aren't
being copied to our ftp server.  I'll be at our main office next week,
and hope to deal with the sysadmins then and find a solution to this
problem.  Otherwise, we may have to look into moving the ftp site.

Ken



From robertl@dgii.com  Wed Jan  8 10:43:00 1997
From: robertl@dgii.com (Robert Lipe)
Date: Wed, 08 Jan 1997 10:43:00 -0000
Subject: emulation on i386-coff, i386-elf patches
Message-ID: <m0vi2Id-0002W5C@rjlhome.dgii.com>

I have a need for an assembler that can switch between generating
i386-elf and i386-coff.   Since the gas doco hints that the emulation
stuff is desirable, but not fully implemented, I decided to take one
stab at it.   Once finished, this would surely be desirable in, say, 
Linux, where it's common to need to flip between the two targets.


The attached patches probably break non-bfd COFF targets and should not
be applied by anyone not willing to slog around in the code a little bit.

If someone that really understands BFD is willing to work with me a little
bit on this, I think it will be useful.

I did most of my testing on progressive-96q4 code.  I did apply the
stuff to the 1217 snaps on ftp.cygnus.com:/private/jelly.  All I had
to change was to add the frob_file_after_relocs vector into the middle
of the format_ops structure.   

I can switch between the two modes with --em=i386coff [ default ]and 
--em=i386elf.   I see that it does the right thing in switching around
the recognized pseudo ops and it generates .o's recognized correctly by
file.   The ELF .o of "hello, world" world even links and runs.

However, the COFF version has a problem that isn't obvious to me.  Here
is a disassembly of the same .s file generated with the native COFF 
assembler and with this assembler in COFF  mode.

$ dis x.o | tail
main
           0:  eb 0d                  jmp    0xd <f>
           2:  68 00 00 00 00         pushl  $0x0
           7:  e8 fc ff ff ff         call   0xfffffffc <8>
           c:  59                     popl   %ecx
           d:  c9                     leave
           e:  c3                     ret
           f:  55                     pushl  %ebp
          10:  8b ec                  movl   %esp,%ebp
          12:  eb ee                  jmp    0xee <2>
(robertl) pento:/home/robertl/tmp/c/x/gas
$ dis x.gas.o | tail
main
           0:  eb 0d                  jmp    0xd <f>
           2:  68 00 00 00 00         pushl  $0x0
           7:  e8 04 00 00 00         call   0x4 <10>
           c:  59                     popl   %ecx
           d:  c9                     leave
           e:  c3                     ret
           f:  55                     pushl  %ebp
          10:  89 e5                  movl   %esp,%ebp
          12:  eb ee                  jmp    0xee <2>


Clearly, the call to printf is very different, and it's distrubing
that one of them is -4 and the other one is 4.



Can anyone work with me on getting this stuff hammered into a usable
form?

Thanx,
RJL








--- gas/Makefile.in_	Mon Aug 19 17:26:40 1996
+++ gas/Makefile.in	Wed Jan  8 10:11:15 1997
@@ -390,11 +390,18 @@
 	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/obj-elf.c
 obj-ecoff.o : $(srcdir)/config/obj-ecoff.c
 	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/obj-ecoff.c
+obj-coff.o : $(srcdir)/config/obj-coff.c
+	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/obj-coff.c
+
 
 e-mipself.o : $(srcdir)/config/e-mipself.c
 	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/e-mipself.c
 e-mipsecoff.o : $(srcdir)/config/e-mipsecoff.c
 	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/e-mipsecoff.c
+e-i386coff.o : $(srcdir)/config/e-i386coff.c
+	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/e-i386coff.c
+e-i386elf.o : $(srcdir)/config/e-i386elf.c
+	$(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $(INCLUDES) $(srcdir)/config/e-i386elf.c
 
 # The m68k operand parser.
 
--- gas/as.c_	Mon Aug 19 12:28:38 1996
+++ gas/as.c	Wed Jan  8 00:01:12 1997
@@ -146,6 +146,7 @@
 
 extern struct emulation mipsbelf, mipslelf, mipself;
 extern struct emulation mipsbecoff, mipslecoff, mipsecoff;
+extern struct emulation i386coff, i386elf;
 
 static struct emulation *const emulations[] = { EMULATIONS };
 static const int n_emulations = sizeof (emulations) / sizeof (emulations[0]);
--- gas/configure_	Wed Sep 11 19:20:03 1996
+++ gas/configure	Wed Jan  8 10:02:57 1997
@@ -1029,6 +1029,7 @@
 			big)	emulation="mipsbelf mipslelf mipself" ;;
 			*)	emulation="mipslelf mipsbelf mipself" ;;
 			esac ;;
+      i386-*-*-elf)	emulation="i386coff i386elf" ;;
     esac
 
     emulations="$emulations $emulation"
@@ -1140,6 +1141,10 @@
 	fmt=elf   file=mipself ;;
     mipsbecoff | mipslecoff)
 	fmt=ecoff file=mipsecoff ;;
+    i386coff)
+	fmt=coff file=i386coff ;;
+    i386elf)
+	fmt=elf file=i386elf ;;
   esac
   formats="$formats $fmt"
   emfiles="$emfiles e-$file.o"
--- gas/obj.h_	Tue Jan  7 23:41:06 1997
+++ gas/obj.h	Tue Jan  7 23:44:09 1997
@@ -68,6 +68,7 @@
 
 extern const struct format_ops elf_format_ops;
 extern const struct format_ops ecoff_format_ops;
+extern const struct format_ops coff_format_ops;
 
 #ifndef this_format
 COMMON const struct format_ops *this_format;
--- /dev/null	Wed Jan  8 10:35:01 1997
+++ gas/config/e-i386elf.c	Wed Jan  8 10:19:46 1997
@@ -0,0 +1,18 @@
+#include "as.h"
+#include "emul.h"
+
+static const char *
+i386elf_bfd_name ()
+{
+  abort ();
+  return NULL;
+}
+
+#define emul_bfd_name	i386elf_bfd_name
+#define emul_format	&elf_format_ops
+
+#define emul_name	"i386elf"
+#define emul_struct_name i386elf
+#define emul_default_endian 0
+#include "emul-target.h"
+
--- /dev/null	Wed Jan  8 10:35:01 1997
+++ gas/config/e-i386coff.c	Wed Jan  8 10:19:31 1997
@@ -0,0 +1,18 @@
+#include "as.h"
+#include "emul.h"
+
+static const char *
+i386coff_bfd_name ()
+{
+  abort ();
+  return NULL;
+}
+
+#define emul_bfd_name	i386coff_bfd_name
+#define emul_format	&coff_format_ops
+
+#define emul_name	"i386coff"
+#define emul_struct_name i386coff
+#define emul_default_endian 0
+#include "emul-target.h"
+
--- gas/config/obj-coff.c_	Tue Jan  7 22:50:56 1997
+++ gas/config/obj-coff.c	Wed Jan  8 02:37:26 1997
@@ -18,7 +18,7 @@
    along with GAS; see the file COPYING.  If not, write to the Free
    Software Foundation, 59 Temple Place - Suite 330, Boston, MA
    02111-1307, USA.  */
-
+#define OBJ_HEADER "obj-coff.h"
 #include "as.h"
 #include "obstack.h"
 #include "subsegs.h"
@@ -328,7 +328,7 @@
 
 
 void
-obj_symbol_new_hook (symbolP)
+coff_obj_symbol_new_hook (symbolP)
      symbolS *symbolP;
 {
   char underscore = 0;		/* Symbol has leading _ */
@@ -869,7 +869,7 @@
 }
 
 void
-obj_read_begin_hook ()
+coff_obj_read_begin_hook ()
 {
   /* These had better be the same.  Usually 18 bytes. */
 #ifndef BFD_HEADERS
@@ -4215,6 +4215,7 @@
 #else
   {"optim", s_ignore, 0},	/* For sun386i cc (?) */
   {"ident", s_ignore, 0},	/* we don't yet handle this. */
+  {"version", s_ignore, 0},	/* we don't yet handle this. */
 #endif
   {"ABORT", s_abort, 0},
 #ifdef TC_M88K
@@ -4223,3 +4224,51 @@
 #endif
   {NULL}			/* end sentinel */
 };				/* obj_pseudo_table */
+
+void coff_pop_insert(void) 
+{
+	pop_insert(obj_pseudo_table) ;
+}
+
+static int 
+coff_sec_sym_ok_for_reloc (sec)
+     asection *sec;
+{
+	return (0);
+}
+
+void no_func(void)
+{
+	abort();
+}
+static int 
+null_func(void)
+{
+	return(0);
+}
+
+const struct format_ops coff_format_ops =
+{
+  bfd_target_coff_flavour,
+  0,
+  1,
+  coff_frob_symbol,
+  coff_frob_file,
+  no_func,
+  0, 0,
+  0, 0,
+  0,
+#if 0
+  obj_generate_asm_lineno,
+#else
+  no_func,
+#endif
+#if 0
+  obj_stab,
+#else
+  no_func,
+#endif
+  coff_sec_sym_ok_for_reloc,
+  coff_pop_insert,
+#if 0
+  obj_set_ext,
+#else
+  no_func,
+#endif
+  coff_obj_read_begin_hook,
+  coff_obj_symbol_new_hook,
+};
--- gas/config/tc-i386.c_	Wed Jan  8 00:57:03 1997
+++ gas/config/tc-i386.c	Wed Jan  8 01:15:08 1997
@@ -3001,6 +3001,19 @@
   return rel;
 }
 
+const char *
+i386_target_format()
+{
+	switch (OUTPUT_FLAVOR) {
+		case bfd_target_coff_flavour: 
+			return "coff-i386" ;
+		case bfd_target_elf_flavour:
+			return "elf32-i386" ;
+		default: 
+			abort() ;
+	}
+}
+
 #else /* ! BFD_ASSEMBLER */
 
 #if (defined(OBJ_AOUT) | defined(OBJ_BOUT))
--- gas/config/tc-i386.h_	Wed Jan  8 01:05:12 1997
+++ gas/config/tc-i386.h	Wed Jan  8 01:19:18 1997
@@ -82,6 +82,7 @@
 #ifdef OBJ_ELF
 #define TARGET_FORMAT		"elf32-i386"
 #endif
+#define TARGET_FORMAT		i386_target_format()
 
 #else /* ! BFD_ASSEMBLER */
 

From ian@cygnus.com  Wed Jan  8 10:50:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Wed, 08 Jan 1997 10:50:00 -0000
Subject: emulation on i386-coff, i386-elf patches
References: <m0vi2Id-0002W5C@rjlhome.dgii.com>
Message-ID: <9701081850.AA12331@tweedledumb.cygnus.com>

   Date: Wed, 8 Jan 1997 12:00:26 -0600 (CST)
   From: Robert Lipe <robertl@dgii.com>

   However, the COFF version has a problem that isn't obvious to me.  Here
   is a disassembly of the same .s file generated with the native COFF=20
   assembler and with this assembler in COFF  mode.

It looks to me like you need to hack md_apply_fix3 in tc-i386.c.  In
general, anything that does an #ifdef OBJ_ELF or #ifdef OBJ_COFF will
have to be hacked.

In fact, I'm not certain that the BFD_ASSEMBLER version of the i386
COFF assembler works correctly.  You need to make sure that if you
configure with --target i386-coff --enable-bfd-assembler the resulting
code works.

By the way, for some reason your patch came in scrambled, with lots of
=20 strings scattered around.  I can never remember how to get rid of
those.

Ian



From raeburn@cygnus.com  Wed Jan  8 12:07:00 1997
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 08 Jan 1997 12:07:00 -0000
Subject: emulation on i386-coff, i386-elf patches
References: <9701081850.AA12331@tweedledumb.cygnus.com>
Message-ID: <tx1rajw3p8f.fsf@cygnus.com>

Ian Lance Taylor <ian@cygnus.com> writes:

> It looks to me like you need to hack md_apply_fix3 in tc-i386.c.  In
> general, anything that does an #ifdef OBJ_ELF or #ifdef OBJ_COFF will
> have to be hacked.

You can check OUTPUT_FLAVOR at run time.  Accesses to flavour-specific
structure members and such can also be conditionalized at compile time
on OBJ_MAYBE_* macros like in the MIPS code.

> In fact, I'm not certain that the BFD_ASSEMBLER version of the i386
> COFF assembler works correctly.  You need to make sure that if you
> configure with --target i386-coff --enable-bfd-assembler the resulting
> code works.

That's the first thing to check....

> By the way, for some reason your patch came in scrambled, with lots of
> =20 strings scattered around.  I can never remember how to get rid of
> those.

In Gnus, turning on MIME processing gets rid of them for me.



From robertl@dgii.com  Wed Jan  8 20:20:00 1997
From: robertl@dgii.com (Robert Lipe)
Date: Wed, 08 Jan 1997 20:20:00 -0000
Subject: emulation on i386-coff, i386-elf patches
References: <9701081850.AA12331@tweedledumb.cygnus.com>
Message-ID: <m0viBxp-0002VuC@rjlhome.dgii.com>

> It looks to me like you need to hack md_apply_fix3 in tc-i386.c.  In
> general, anything that does an #ifdef OBJ_ELF or #ifdef OBJ_COFF will
> have to be hacked.

Excellent catch, Ian.

Carving up tc-i386.c gave me exactly the results I needed.   The ELF
emulation mode of the assembler seems to be in excellent shape.  I just
watched the COFF side trip over itself, but the failure case needs trimmed
up considerably:

$ make CC='gcc ' CFLAGS=-g
gcc  -c -I. -I../../gas-961217/binutils -I../bfd -I../../gas-961217/binutils/../
bfd -I../../gas-961217/binutils/../include  -g ../../gas-961217/binutils/prdbg.c

gcc   -g  -o objdump objdump.o prdbg.o rddbg.o debug.o stabs.o ieee.o rdcoff.o -
L../bfd -lbfd -L../opcodes -lopcodes bucomm.o version.o filemode.o -L../bfd -lbf
d ../libiberty/libiberty.a
ld: line nbr entry (1125 0) found for non-relocatable symbol: section .text, fil
e prdbg.o

Note: this isn't GNU ld.

Rebuilding that specific file without -g makes it go away.   I'll pursue.


> In fact, I'm not certain that the BFD_ASSEMBLER version of the i386
> COFF assembler works correctly.  You need to make sure that if you
> configure with --target i386-coff --enable-bfd-assembler the resulting
> code works.

Building that stand-alone results in it being unable to resolve:
	obj_read_begin_hook                 read.o
	obj_symbol_new_hook                 symbols.o

I didn't pursue that aspect further.

Since you and Ken both sound doubtful of BFD_ASSEMBLER on i386 COFF, 
could you offer hints on suspected problem areas?   Sounds like I 
should take the time to get a 'make check' working.


Thanx, guys.

RJL



From robertl@dgii.com  Wed Jan  8 22:03:00 1997
From: robertl@dgii.com (Robert Lipe)
Date: Wed, 08 Jan 1997 22:03:00 -0000
Subject: Patch to improve consistency in GAS
Message-ID: <m0viDZV-0002WDC@rjlhome.dgii.com>

Please apply this patch to GAS.   Since this is my code, I feel pretty
good about the relative "safety" of this move.   It allows the .note
section to be generated for building under ELF while not bringing a bunch
of ELF-isms into obj-coff.

It should be considered independently from other work in the assembler
emulation stuff.

Thank you.
RJL




Wed Jan  8 23:24:05 CST 1997 Robert Lipe <robertl@dgii.com>

	* config/tc-i386.c (sco_id): Moved from here
 	  config/obj-elf.c (sco_id): to here.   Adding the
	  identifier really is an SCO ELF specific thing, not 
	  just a SCO x86 specific thing.

	


*** gas.orig/config/tc-i386.c	Tue Dec 17 03:05:30 1996
--- gas/config/tc-i386.c	Wed Jan  8 23:08:22 1997
***************
*** 3073,3171 ****
  
  #endif /* BFD_ASSEMBLER? */
  
- #ifdef SCO_ELF
- 
- /* Heavily plagarized from obj_elf_version.  The idea is to emit the
-    SCO specific identifier in the .notes section to satisfy the SCO
-    linker.
- 
-    This looks more complicated than it really is.  As opposed to the
-    "obvious" solution, this should handle the cross dev cases
-    correctly.  (i.e, hosting on a 64 bit big endian processor, but
-    generating SCO Elf code) Efficiency isn't a concern, as there
-    should be exactly one of these sections per object module.
- 
-    SCO OpenServer 5 identifies it's ELF modules with a standard ELF
-    .note section.
- 
-    int_32 namesz  = 4 ;  Name size 
-    int_32 descsz  = 12 ; Descriptive information 
-    int_32 type    = 1 ;  
-    char   name[4] = "SCO" ; Originator name ALWAYS SCO + NULL 
-    int_32 version = (major ver # << 16)  | version of tools ;
-    int_32 source  = (tool_id << 16 ) | 1 ;
-    int_32 info    = 0 ;    These are set by the SCO tools, but we
-                            don't know enough about the source 
- 			   environment to set them.  SCO ld currently
- 			   ignores them, and recommends we set them
- 			   to zero.  */
- 
- #define SCO_MAJOR_VERSION 0x1
- #define SCO_MINOR_VERSION 0x1
- 
- void
- sco_id ()
- {
-   char *name;
-   unsigned int c;
-   char ch;
-   char *p;
-   asection *seg = now_seg;
-   subsegT subseg = now_subseg;
-   Elf_Internal_Note i_note;
-   Elf_External_Note e_note;
-   asection *note_secp = (asection *) NULL;
-   int i, len;
- 
-   /* create the .note section */
- 
-   note_secp = subseg_new (".note", 0);
-   bfd_set_section_flags (stdoutput,
- 			 note_secp,
- 			 SEC_HAS_CONTENTS | SEC_READONLY);
- 
-   /* process the version string */
- 
-   i_note.namesz = 4; 
-   i_note.descsz = 12;		/* 12 descriptive bytes */
-   i_note.type = NT_VERSION;	/* Contains a version string */
- 
-   p = frag_more (sizeof (i_note.namesz));
-   md_number_to_chars (p, (valueT) i_note.namesz, 4);
- 
-   p = frag_more (sizeof (i_note.descsz));
-   md_number_to_chars (p, (valueT) i_note.descsz, 4);
- 
-   p = frag_more (sizeof (i_note.type));
-   md_number_to_chars (p, (valueT) i_note.type, 4);
- 
-   p = frag_more (4);
-   strcpy (p, "SCO"); 
- 
-   /* Note: this is the version number of the ELF we're representing */
-   p = frag_more (4);
-   md_number_to_chars (p, (SCO_MAJOR_VERSION << 16) | (SCO_MINOR_VERSION), 4);
- 
-   /* Here, we pick a magic number for ourselves (yes, I "registered"
-      it with SCO.  The bottom bit shows that we are compat with the
-      SCO ABI.  */
-   p = frag_more (4);
-   md_number_to_chars (p, 0x4c520000 | 0x0001, 4);
- 
-   /* If we knew (or cared) what the source language options were, we'd
-      fill them in here.  SCO has given us permission to ignore these
-      and just set them to zero.  */
-   p = frag_more (4);
-   md_number_to_chars (p, 0x0000, 4);
-  
-   frag_align (2, 0); 
- 
-   /* We probably can't restore the current segment, for there likely
-      isn't one yet...  */
-   if (seg && subseg)
-     subseg_set (seg, subseg);
- }
- 
- #endif /* SCO_ELF */
- 
  /* end of tc-i386.c */
--- 3096,3099 ----
*** gas.orig/config/obj-elf.c	Tue Dec 17 03:05:25 1996
--- gas/config/obj-elf.c	Wed Jan  8 23:08:47 1997
***************
*** 1284,1289 ****
--- 1284,1386 ----
  #endif /* NEED_ECOFF_DEBUG */
  }
  
+ #ifdef SCO_ELF
+ 
+ /* Heavily plagarized from obj_elf_version.  The idea is to emit the
+    SCO specific identifier in the .notes section to satisfy the SCO
+    linker.
+ 
+    This looks more complicated than it really is.  As opposed to the
+    "obvious" solution, this should handle the cross dev cases
+    correctly.  (i.e, hosting on a 64 bit big endian processor, but
+    generating SCO Elf code) Efficiency isn't a concern, as there
+    should be exactly one of these sections per object module.
+ 
+    SCO OpenServer 5 identifies it's ELF modules with a standard ELF
+    .note section.
+ 
+    int_32 namesz  = 4 ;  Name size 
+    int_32 descsz  = 12 ; Descriptive information 
+    int_32 type    = 1 ;  
+    char   name[4] = "SCO" ; Originator name ALWAYS SCO + NULL 
+    int_32 version = (major ver # << 16)  | version of tools ;
+    int_32 source  = (tool_id << 16 ) | 1 ;
+    int_32 info    = 0 ;    These are set by the SCO tools, but we
+                            don't know enough about the source 
+ 			   environment to set them.  SCO ld currently
+ 			   ignores them, and recommends we set them
+ 			   to zero.  */
+ 
+ #define SCO_MAJOR_VERSION 0x1
+ #define SCO_MINOR_VERSION 0x1
+ 
+ void
+ sco_id ()
+ {
+ 
+   char *name;
+   unsigned int c;
+   char ch;
+   char *p;
+   asection *seg = now_seg;
+   subsegT subseg = now_subseg;
+   Elf_Internal_Note i_note;
+   Elf_External_Note e_note;
+   asection *note_secp = (asection *) NULL;
+   int i, len;
+ 
+   /* create the .note section */
+ 
+   note_secp = subseg_new (".note", 0);
+   bfd_set_section_flags (stdoutput,
+ 			 note_secp,
+ 			 SEC_HAS_CONTENTS | SEC_READONLY);
+ 
+   /* process the version string */
+ 
+   i_note.namesz = 4; 
+   i_note.descsz = 12;		/* 12 descriptive bytes */
+   i_note.type = NT_VERSION;	/* Contains a version string */
+ 
+   p = frag_more (sizeof (i_note.namesz));
+   md_number_to_chars (p, (valueT) i_note.namesz, 4);
+ 
+   p = frag_more (sizeof (i_note.descsz));
+   md_number_to_chars (p, (valueT) i_note.descsz, 4);
+ 
+   p = frag_more (sizeof (i_note.type));
+   md_number_to_chars (p, (valueT) i_note.type, 4);
+ 
+   p = frag_more (4);
+   strcpy (p, "SCO"); 
+ 
+   /* Note: this is the version number of the ELF we're representing */
+   p = frag_more (4);
+   md_number_to_chars (p, (SCO_MAJOR_VERSION << 16) | (SCO_MINOR_VERSION), 4);
+ 
+   /* Here, we pick a magic number for ourselves (yes, I "registered"
+      it with SCO.  The bottom bit shows that we are compat with the
+      SCO ABI.  */
+   p = frag_more (4);
+   md_number_to_chars (p, 0x4c520000 | 0x0001, 4);
+ 
+   /* If we knew (or cared) what the source language options were, we'd
+      fill them in here.  SCO has given us permission to ignore these
+      and just set them to zero.  */
+   p = frag_more (4);
+   md_number_to_chars (p, 0x0000, 4);
+  
+   frag_align (2, 0); 
+ 
+   /* We probably can't restore the current segment, for there likely
+      isn't one yet...  */
+   if (seg && subseg)
+     subseg_set (seg, subseg);
+ 
+ }
+ 
+ #endif /* SCO_ELF */
+ 
  const struct format_ops elf_format_ops =
  {
    bfd_target_elf_flavour,

From robertl@dgii.com  Wed Jan  8 22:04:00 1997
From: robertl@dgii.com (Robert Lipe)
Date: Wed, 08 Jan 1997 22:04:00 -0000
Subject: gas fixes for x86 elf/coff emulations
Message-ID: <m0viDaG-0002WGC@rjlhome.dgii.com>

As promised, here's the additional work in config/tc-i386.c.

I have now built binutils with gcc and the assembler with yesterday's
patches plus this work.  Problems remain with debugging (-gstabs aborts
in COFF, COFF debugging gets tripped up by certain files) but in loose
generalities, things work.      Things seem to work quite well in ELF.

I don't know at this time how much of the problems I'm seeing are
artifacts of of the questionable (?) --iwth-bfd-assembler version
of the COFF stuff.

Whitespace may need to be adjusted.

RJL


Wed Jan  8 23:28:34 CST 1997 Robert Lipe <robertl@dgii.com>
	* config/tc-i386.c:  Several changes to allow emulations
	to work for x86 ELF and COFF.


*** gas.orig/config/tc-i386.c	Tue Dec 17 03:05:30 1996
--- gas/config/tc-i386.c	Wed Jan  8 23:08:22 1997
***************
*** 104,110 ****
  
  /* This array holds the chars that always start a comment.  If the
     pre-processor is disabled, these aren't very useful */
! #if defined (TE_I386AIX) || defined (OBJ_ELF)
  const char comment_chars[] = "#/";
  #else
  const char comment_chars[] = "#";
--- 104,110 ----
  
  /* This array holds the chars that always start a comment.  If the
     pre-processor is disabled, these aren't very useful */
! #if defined (TE_I386AIX) || defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
  const char comment_chars[] = "#/";
  #else
  const char comment_chars[] = "#";
***************
*** 118,124 ****
     #NO_APP at the beginning of its output. */
  /* Also note that comments started like this one will always work if
     '/' isn't otherwise defined.  */
! #if defined (TE_I386AIX) || defined (OBJ_ELF)
  const char line_comment_chars[] = "";
  #else
  const char line_comment_chars[] = "/";
--- 118,124 ----
     #NO_APP at the beginning of its output. */
  /* Also note that comments started like this one will always work if
     '/' isn't otherwise defined.  */
! #if defined (TE_I386AIX) || defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
  const char line_comment_chars[] = "";
  #else
  const char line_comment_chars[] = "/";
***************
*** 555,564 ****
        operand_chars[(unsigned char) *p] = *p;
    }
  
! #ifdef OBJ_ELF
    record_alignment (text_section, 2);
    record_alignment (data_section, 2);
    record_alignment (bss_section, 2);
  #endif
  }
  
--- 555,566 ----
        operand_chars[(unsigned char) *p] = *p;
    }
  
! #if defined  (OBJ_ELF) ||  defined (OBJ_MAYBE_ELF)
!   if (OUTPUT_FLAVOR == bfd_target_elf_flavour) {
    record_alignment (text_section, 2);
    record_alignment (data_section, 2);
    record_alignment (bss_section, 2);
+   }
  #endif
  }
  
***************
*** 2631,2640 ****
    if (fixP->fx_r_type == BFD_RELOC_32_PCREL && fixP->fx_addsy)
      {
  #ifndef OBJ_AOUT
        value += fixP->fx_where + fixP->fx_frag->fr_address;
  #endif
! #ifdef OBJ_ELF
!       if (S_GET_SEGMENT (fixP->fx_addsy) == seg
  	  || (fixP->fx_addsy->bsym->flags & BSF_SECTION_SYM) != 0)
  	{
  	  /* Yes, we add the values in twice.  This is because
--- 2633,2644 ----
    if (fixP->fx_r_type == BFD_RELOC_32_PCREL && fixP->fx_addsy)
      {
  #ifndef OBJ_AOUT
+       if (OUTPUT_FLAVOR == bfd_target_elf_flavour) 
        value += fixP->fx_where + fixP->fx_frag->fr_address;
  #endif
! #if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
!       if (OUTPUT_FLAVOR == bfd_target_elf_flavour) 
!       if (S_GET_SEGMENT (fixP->fx_addsy) == seg 
  	  || (fixP->fx_addsy->bsym->flags & BSF_SECTION_SYM) != 0)
  	{
  	  /* Yes, we add the values in twice.  This is because
***************
*** 2648,2655 ****
  
    /* Fix a few things - the dynamic linker expects certain values here,
       and we must not dissappoint it. */
! #ifdef OBJ_ELF
!   if (fixP->fx_addsy)
      switch(fixP->fx_r_type) {
      case BFD_RELOC_386_PLT32:
        /* Make the jump instruction point to the address of the operand.  At
--- 2652,2660 ----
  
    /* Fix a few things - the dynamic linker expects certain values here,
       and we must not dissappoint it. */
! #if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
!   if ( (OUTPUT_FLAVOR == bfd_target_elf_flavour)  && 
! 	fixP->fx_addsy)
      switch(fixP->fx_r_type) {
      case BFD_RELOC_386_PLT32:
        /* Make the jump instruction point to the address of the operand.  At
***************
*** 2838,2856 ****
        flag_do_long_jump = 1;
        break;
  
! #ifdef OBJ_ELF
        /* -k: Ignore for FreeBSD compatibility.  */
      case 'k':
        break;
  
        /* -V: SVR4 argument to print version ID.  */
      case 'V':
!       print_version_id ();
        break;
  
        /* -Qy, -Qn: SVR4 arguments controlling whether a .comment section
  	 should be emitted or not.  FIXME: Not implemented.  */
      case 'Q':
        break;
  #endif
  
--- 2843,2866 ----
        flag_do_long_jump = 1;
        break;
  
! #if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
        /* -k: Ignore for FreeBSD compatibility.  */
      case 'k':
+   	if (OUTPUT_FLAVOR == bfd_target_elf_flavour) return 1 ;
        break;
  
        /* -V: SVR4 argument to print version ID.  */
      case 'V':
!   	if (OUTPUT_FLAVOR == bfd_target_elf_flavour) 
! 	      print_version_id ();
! 	else
! 		return 0 ;
        break;
  
        /* -Qy, -Qn: SVR4 arguments controlling whether a .comment section
  	 should be emitted or not.  FIXME: Not implemented.  */
      case 'Q':
+   	if (OUTPUT_FLAVOR == bfd_target_elf_flavour)  return 1 ;
        break;
  #endif
  
***************
*** 3003,3008 ****
--- 3013,3031 ----
    return rel;
  }
  
+ const char *
+ i386_target_format()
+ {
+ 	switch (OUTPUT_FLAVOR) {
+ 		case bfd_target_coff_flavour: 
+ 			return "coff-i386" ;
+ 		case bfd_target_elf_flavour:
+ 			return "elf32-i386" ;
+ 		default: 
+ 			abort() ;
+ 	}
+ }
+ 
  #else /* ! BFD_ASSEMBLER */
  
  #if (defined(OBJ_AOUT) | defined(OBJ_BOUT))

From ian@cygnus.com  Thu Jan  9 09:06:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 09 Jan 1997 09:06:00 -0000
Subject: emulation on i386-coff, i386-elf patches
References: <m0viBxp-0002VuC@rjlhome.dgii.com>
Message-ID: <199701091706.JAA09307@rtl.cygnus.com>

   Date: Wed, 8 Jan 1997 22:19:36 -0600 (CST)
   From: Robert Lipe <robertl@dgii.com>

   > In fact, I'm not certain that the BFD_ASSEMBLER version of the i386
   > COFF assembler works correctly.  You need to make sure that if you
   > configure with --target i386-coff --enable-bfd-assembler the resulting
   > code works.

   Building that stand-alone results in it being unable to resolve:
	   obj_read_begin_hook                 read.o
	   obj_symbol_new_hook                 symbols.o

   I didn't pursue that aspect further.

You can probably define both to be empty macros in tc-i386.h.

   Since you and Ken both sound doubtful of BFD_ASSEMBLER on i386 COFF, 
   could you offer hints on suspected problem areas?   Sounds like I 
   should take the time to get a 'make check' working.

Since you have access to an i386 COFF native system, the best check is
to run `make CC=gcc bootstrap' in the gas build directory.  That will
do a three stage of gas with itself.

The problem areas will be md_apply_fix and tc_gen_reloc.  You will
need to tweak them in apparently senseless fashion until they do the
right thing (you should be able to figure out what the right thing is
by looking at the object code generated by the non-BFD version).
Unfortunately, gas reloc handling is broken, and fixing it is hard.

Ian



From raeburn@cygnus.com  Sat Jan 18 17:41:00 1997
From: raeburn@cygnus.com (Ken Raeburn)
Date: Sat, 18 Jan 1997 17:41:00 -0000
Subject: binutils snapshots
Message-ID: <9701190141.AA04169@cujo.cygnus.com>

The automatic snapshot code is still not working (due to firewall
lossage), but I forced through one run manually tonight.  Some 130K
(gzipped) of diffs have been made since the last snapshot in December.
If we still can't get the automatic scripts working, I'll try to run
this by hand more often.

Ken



From sean@mcneil.com  Sun Jan 26 17:17:00 1997
From: sean@mcneil.com (Sean McNeil)
Date: Sun, 26 Jan 1997 17:17:00 -0000
Subject: subscribe
Message-ID: <01BC0BAC.C8B50C00@mcneil.mcneil.com>

subscribe sean@mcneil.com




From sean@mcneil.com  Sun Jan 26 17:22:00 1997
From: sean@mcneil.com (Sean McNeil)
Date: Sun, 26 Jan 1997 17:22:00 -0000
Subject: subscribe
Message-ID: <01BC0BAD.725C2360@mcneil.mcneil.com>

I apologize for this.  I mis-typed and forgot the -request.  Sorry for the clutter.




From joel@merlin.gcs.redstone.army.mil  Tue Jan 28 12:30:00 1997
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill <joel@merlin.gcs.redstone.army.mil>)
Date: Tue, 28 Jan 1997 12:30:00 -0000
Subject: config/mh-linux missing in  gas-970127.tar.gz
Message-ID: <Pine.SV4.3.91.970128142551.3327A-100000@merlin>

I am doing a one tree build of ppc-rtems on an i486-linux host and
switched from binutils 2.7 to gas-970127 and while configuring it
complained about config/mh-linux which was present in 2.7 but is not
in the latest snapshots.

I copied the one from 2.7 into the snapshot and it appears to be
building fine now.

--joel

Joel Sherrill                    Sr. Computer Scientist
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985





From ian@cygnus.com  Tue Jan 28 12:40:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 28 Jan 1997 12:40:00 -0000
Subject: config/mh-linux missing in  gas-970127.tar.gz
References: <Pine.SV4.3.91.970128142551.3327A-100000@merlin>
Message-ID: <199701282039.PAA22944@sanguine.cygnus.com>

   Date: Tue, 28 Jan 1997 14:26:20 -0600 (CST)
   From: "Joel Sherrill <joel@merlin.gcs.redstone.army.mil>" <joel@merlin.gcs.redstone.army.mil>

   I am doing a one tree build of ppc-rtems on an i486-linux host and
   switched from binutils 2.7 to gas-970127 and while configuring it
   complained about config/mh-linux which was present in 2.7 but is not
   in the latest snapshots.

   I copied the one from 2.7 into the snapshot and it appears to be
   building fine now.

I don't think there is a bug here.  The file mh-linux was
intentionally removed, since it was useless.

I am guessing that you are using the same object directory, and
updated the sources, and didn't rerun configure, and got an error from
Makefile telling you that mh-linux could not be found.  The fix is to
run ./config.status by hand.  This will generate the correct Makefile
with the correct dependencies.

Although updating the sources with the same object directory will
normally work, you can't assume that it will always work.  Sometimes
you must explicitly reconfigure.

Ian



From joel@OARcorp.com  Mon Sep 15 12:05:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 15 Sep 1997 12:05:00 -0000
Subject: binutils 2.8.1 cpu32 bug
Message-ID: <Pine.BSF.3.96.970915140301.341C-100000@vespucci.advicom.net>

Here is a fix I received from an RTEMS user.  This was in binutils 2.8.1
and I am not sure whether or not it has been fixed since.

--joel

=====================================================================
*** binutils-2.8.1/opcodes/m68k-opc.c   Wed Aug  6 09:47:31 1997
--- /usr/src/local/gnu/src/binutils-2.8.1.0.1/opcodes/m68k-opc.c      
   Wed Jul 23 21:09:13 1997
***************
*** 1760,1766 ****

  #define TBL1(name,signed,round,size)                                  \
    {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
!      two(0177700,0107777), "`sD1", cpu32 },                           \
    {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
       two(0177770,0107770), "DsD3D1", cpu32 }
  #define TBL(name1, name2, name3, s, r) \
--- 1760,1766 ----

  #define TBL1(name,signed,round,size)                                  \
    {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
!      two(0177700,0107777), "@lD1", cpu32 },                           \
    {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
       two(0177770,0107770), "DsD3D1", cpu32 }
  #define TBL(name1, name2, name3, s, r) \
***************
*** 1825,1837 ****

  {"trapv",     one(0047166),   one(0177777), "", m68000up },

! {"tstb",      one(0045000),   one(0177700), ";b", m68020up | mcf5200 },
  {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
! {"tstw",      one(0045100),   one(0177700), "*w", m68020up | mcf5200 },
! {"tstw",      one(0045110),   one(0177700), "As", cpu32 },
  {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
! {"tstl",      one(0045200),   one(0177700), "*l", m68020up | mcf5200 },
! {"tstl",      one(0045210),   one(0177700), "As", cpu32 },
  {"tstl",      one(0045200),   one(0177700), "@l", m68000up },

  {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },
--- 1825,1835 ----

  {"trapv",     one(0047166),   one(0177777), "", m68000up },

! {"tstb",      one(0045000),   one(0177700), ";b", m68020up |  
mcf5200 | cpu32 },
  {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
! {"tstw",      one(0045100),   one(0177700), "*w", m68020up |  
mcf5200 | cpu32 },
  {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
! {"tstl",      one(0045200),   one(0177700), "*l", m68020up |  
mcf5200 | cpu32 },
  {"tstl",      one(0045200),   one(0177700), "@l", m68000up },

  {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },




From ian@cygnus.com  Wed Sep 24 10:42:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Wed, 24 Sep 1997 10:42:00 -0000
Subject: binutils 2.8.1 cpu32 bug
References: <Pine.BSF.3.96.970915140301.341C-100000@vespucci.advicom.net>
Message-ID: <199709241742.NAA05637@subrogation.cygnus.com>

   Date: Mon, 15 Sep 1997 14:05:26 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   Here is a fix I received from an RTEMS user.  This was in binutils 2.8.1
   and I am not sure whether or not it has been fixed since.

   --joel

   =====================================================================
   *** binutils-2.8.1/opcodes/m68k-opc.c   Wed Aug  6 09:47:31 1997
   --- /usr/src/local/gnu/src/binutils-2.8.1.0.1/opcodes/m68k-opc.c      
      Wed Jul 23 21:09:13 1997
   ***************
   *** 1760,1766 ****

     #define TBL1(name,signed,round,size)                                  \
       {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
   !      two(0177700,0107777), "`sD1", cpu32 },                           \
       {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
	  two(0177770,0107770), "DsD3D1", cpu32 }
     #define TBL(name1, name2, name3, s, r) \
   --- 1760,1766 ----

     #define TBL1(name,signed,round,size)                                  \
       {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
   !      two(0177700,0107777), "@lD1", cpu32 },                           \
       {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
	  two(0177770,0107770), "DsD3D1", cpu32 }
     #define TBL(name1, name2, name3, s, r) \

I don't understand this patch, and I would need more information.  My
m680x0 book indicates that the original value is correct, since the
set of operands permitted for the tbl instructions are very limited.

   ***************
   *** 1825,1837 ****

     {"trapv",     one(0047166),   one(0177777), "", m68000up },

   ! {"tstb",      one(0045000),   one(0177700), ";b", m68020up | mcf5200 },
     {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
   ! {"tstw",      one(0045100),   one(0177700), "*w", m68020up | mcf5200 },
   ! {"tstw",      one(0045110),   one(0177700), "As", cpu32 },
     {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
   ! {"tstl",      one(0045200),   one(0177700), "*l", m68020up | mcf5200 },
   ! {"tstl",      one(0045210),   one(0177700), "As", cpu32 },
     {"tstl",      one(0045200),   one(0177700), "@l", m68000up },

     {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },
   --- 1825,1835 ----

     {"trapv",     one(0047166),   one(0177777), "", m68000up },

   ! {"tstb",      one(0045000),   one(0177700), ";b", m68020up |  
   mcf5200 | cpu32 },
     {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
   ! {"tstw",      one(0045100),   one(0177700), "*w", m68020up |  
   mcf5200 | cpu32 },
     {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
   ! {"tstl",      one(0045200),   one(0177700), "*l", m68020up |  
   mcf5200 | cpu32 },
     {"tstl",      one(0045200),   one(0177700), "@l", m68000up },

     {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },

I checked in a version of this patch.  Oddly, the original source does
not appear in my sources.  Thanks for sending it.

Ian


From joel@OARcorp.com  Wed Sep 24 14:08:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Wed, 24 Sep 1997 14:08:00 -0000
Subject: binutils 2.8.1 cpu32 bug
References: <199709241742.NAA05637@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.970924160711.26001A-100000@vespucci.advicom.net>

The user was on a 68360.  I have a manual if you don't.  Jus tlet me know
what to look up.  I do not know offhand what the actual bug being fixed
was.  Do you want me to ask them for a test case or example?

--joel

On Wed, 24 Sep 1997, Ian Lance Taylor wrote:

>    Date: Mon, 15 Sep 1997 14:05:26 -0500 (CDT)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    Here is a fix I received from an RTEMS user.  This was in binutils 2.8.1
>    and I am not sure whether or not it has been fixed since.
> 
>    --joel
> 
>    =====================================================================
>    *** binutils-2.8.1/opcodes/m68k-opc.c   Wed Aug  6 09:47:31 1997
>    --- /usr/src/local/gnu/src/binutils-2.8.1.0.1/opcodes/m68k-opc.c      
>       Wed Jul 23 21:09:13 1997
>    ***************
>    *** 1760,1766 ****
> 
>      #define TBL1(name,signed,round,size)                                  \
>        {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
>    !      two(0177700,0107777), "`sD1", cpu32 },                           \
>        {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
> 	  two(0177770,0107770), "DsD3D1", cpu32 }
>      #define TBL(name1, name2, name3, s, r) \
>    --- 1760,1766 ----
> 
>      #define TBL1(name,signed,round,size)                                  \
>        {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)|0000400),   \
>    !      two(0177700,0107777), "@lD1", cpu32 },                           \
>        {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),           \
> 	  two(0177770,0107770), "DsD3D1", cpu32 }
>      #define TBL(name1, name2, name3, s, r) \
> 
> I don't understand this patch, and I would need more information.  My
> m680x0 book indicates that the original value is correct, since the
> set of operands permitted for the tbl instructions are very limited.
> 
>    ***************
>    *** 1825,1837 ****
> 
>      {"trapv",     one(0047166),   one(0177777), "", m68000up },
> 
>    ! {"tstb",      one(0045000),   one(0177700), ";b", m68020up | mcf5200 },
>      {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
>    ! {"tstw",      one(0045100),   one(0177700), "*w", m68020up | mcf5200 },
>    ! {"tstw",      one(0045110),   one(0177700), "As", cpu32 },
>      {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
>    ! {"tstl",      one(0045200),   one(0177700), "*l", m68020up | mcf5200 },
>    ! {"tstl",      one(0045210),   one(0177700), "As", cpu32 },
>      {"tstl",      one(0045200),   one(0177700), "@l", m68000up },
> 
>      {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },
>    --- 1825,1835 ----
> 
>      {"trapv",     one(0047166),   one(0177777), "", m68000up },
> 
>    ! {"tstb",      one(0045000),   one(0177700), ";b", m68020up |  
>    mcf5200 | cpu32 },
>      {"tstb",      one(0045000),   one(0177700), "@b", m68000up },
>    ! {"tstw",      one(0045100),   one(0177700), "*w", m68020up |  
>    mcf5200 | cpu32 },
>      {"tstw",      one(0045100),   one(0177700), "@w", m68000up },
>    ! {"tstl",      one(0045200),   one(0177700), "*l", m68020up |  
>    mcf5200 | cpu32 },
>      {"tstl",      one(0045200),   one(0177700), "@l", m68000up },
> 
>      {"unlk",      one(0047130),   one(0177770), "As", m68000up | mcf5200 },
> 
> I checked in a version of this patch.  Oddly, the original source does
> not appear in my sources.  Thanks for sending it.
> 
> Ian
> 



From ian@cygnus.com  Wed Sep 24 15:42:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Wed, 24 Sep 1997 15:42:00 -0000
Subject: binutils 2.8.1 cpu32 bug
References: <Pine.BSF.3.96.970924160711.26001A-100000@vespucci.advicom.net>
Message-ID: <199709242242.SAA12246@subrogation.cygnus.com>

   Date: Wed, 24 Sep 1997 16:08:10 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   The user was on a 68360.  I have a manual if you don't.  Jus tlet me know
   what to look up.  I do not know offhand what the actual bug being fixed
   was.  Do you want me to ask them for a test case or example?

I do have a manual.  According to my reading of the manual, the
existing code is correct.  So I guess I want to know why this patch
should be made, since the current code looks right to me.  A test case
would be a good start.

Ian


From joel@OARcorp.com  Thu Sep 25 06:16:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Thu, 25 Sep 1997 06:16:00 -0000
Subject: binutils bug you reported (fwd)
Message-ID: <Pine.BSF.3.96.970925073710.16864A-100000@vespucci.advicom.net>

Here is a little more information on the binutils patch I got from a user.

If it is not enough or you need me to send you a manual page or two, let
me know.

--joel


---------- Forwarded message ----------
Date: Wed, 24 Sep 97 16:09:00 -0600
From: Eric Norum <eric@skatter.USask.Ca>
To: Joel Sherrill <joel@OARcorp.com>
Subject: Re: binutils bug you reported

You wrote:
> Do you have a test case or description? Ian was going to merge it
> but did not understand why it was necessary.
>
> --joel
>

Here's the file I got from the Linux people:
===================================================================

I guess, there are two small bug in gas (binutils 2.8.1), concerning cpu32
targets (68332).

1. 'tst.l a0' won't assemble any more (it worked fine in version 2.6). The
        reason is, that this addressing mode is allowed in
        'binutils-2.8.1/opcodes/m68k-opc.c'only for targets 'm68020up'. 
        My cpu32 reference manual (cpu32rm/ad rev 1) allows this  
addressing
        mode for word and long word operation

        I suggest one should change /binutils-2.8.1/opcodes/m68k-opc.c:

        original code:

        {"tstb", one(0045000), one(0177700), ";b", m68020up | mcf5200 },
        {"tstb", one(0045000), one(0177700), "@b", m68000up },
        {"tstw", one(0045100), one(0177700), "*w", m68020up | mcf5200 },
        {"tstw", one(0045100), one(0177700), "@w", m68000up },
        {"tstl", one(0045200), one(0177700), "*l", m68020up | mcf5200 },
        {"tstl", one(0045200), one(0177700), "@l", m68000up },

        new code:

>>>     {"tstb", one(0045000), one(0177700), ";b", m68020up |  
mcf5200 | cpu32 },
        {"tstb", one(0045000), one(0177700), "@b", m68000up },
>>>     {"tstw", one(0045100), one(0177700), "*w", m68020up |  
mcf5200 | cpu32 },
        {"tstw", one(0045100), one(0177700), "@w", m68000up },
>>>     {"tstl", one(0045200), one(0177700), "*l", m68020up |  
mcf5200 | cpu32 },
        {"tstl", one(0045200), one(0177700), "@l", m68000up },

2. 'tblu.w a0@,d0' won't assemble. The error message tells something about
        'invalid operand'. The table lookup and interpolate opcode  
(tbls, tblsn,
        tblu, tblun) allows two types of operands:

          eg:
                tblu.<size>     <ea>,Dx
                tblu.<size>     Dym:Dyn,Dx

        The first one (wich is not allowed by gas) is similar to the
        addressing mode of the 'mulu' opcode, except immediate data,
        so made the following change to  
/binutils-2.8.1/opcodes/m68k-opc.c:

        original code:

        #define TBL1(name,signed,round,size)                          
       \
          {name, two(0174000,  
(signed<<11)|(!round<<10)|(size<<6)|0000400), \
             two(0177700,0107777), "`sD1", cpu32 },                   
       \
          {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),   
       \
             two(0177770,0107770), "DsD3D1", cpu32 }

        new code:

        #define TBL1(name,signed,round,size)                          
       \
          {name, two(0174000,  
(signed<<11)|(!round<<10)|(size<<6)|0000400), \
>>>          two(0177700,0107777), "@lD1", cpu32 },                   
       \
          {name, two(0174000, (signed<<11)|(!round<<10)|(size<<6)),   
       \
             two(0177770,0107770), "DsD3D1", cpu32 }


---
Eric Norum                                 eric@skatter.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.



From ian@cygnus.com  Thu Sep 25 10:00:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 25 Sep 1997 10:00:00 -0000
Subject: binutils bug you reported (fwd)
References: <Pine.BSF.3.96.970925073710.16864A-100000@vespucci.advicom.net>
Message-ID: <199709251700.NAA21402@subrogation.cygnus.com>

   Date: Thu, 25 Sep 1997 07:38:20 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   2. 'tblu.w a0@,d0' won't assemble. The error message tells something about
	   'invalid operand'. The table lookup and interpolate opcode  
   (tbls, tblsn,
	   tblu, tblun) allows two types of operands:

	     eg:
		   tblu.<size>     <ea>,Dx
		   tblu.<size>     Dym:Dyn,Dx

Interesting.  My basic Motorola manual says that tbls does not permits
a0@, although it does permit a0@-, and that is what gas implements.
However, the manual also says that tblu permits both a0@ and a0@-, and
gas does not implement that.

I checked a CPU32 specific manual, and it says that both instructions
support a0@, and neither supports a0@-.

I couldn't get any useful information from the Motorola web site.

Since a0@- doesn't really make sense for these instructions, I'll
change gas to not permit a0@-, but to permit a0@, for both.

Either way, the submitted patch is wrong, since it permits operand
types which are not actually permitted.

Ian


From joel@OARcorp.com  Thu Sep 25 10:28:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Thu, 25 Sep 1997 10:28:00 -0000
Subject: binutils bug you reported (fwd)
References: <199709251700.NAA21402@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.970925122333.4107B-100000@vespucci.advicom.net>

On Thu, 25 Sep 1997, Ian Lance Taylor wrote:
> 
>    2. 'tblu.w a0@,d0' won't assemble. The error message tells something about
> 	   'invalid operand'. The table lookup and interpolate opcode  
>    (tbls, tblsn,
> 	   tblu, tblun) allows two types of operands:
> 
> 	     eg:
> 		   tblu.<size>     <ea>,Dx
> 		   tblu.<size>     Dym:Dyn,Dx
> 
> Interesting.  My basic Motorola manual says that tbls does not permits
> a0@, although it does permit a0@-, and that is what gas implements.
> However, the manual also says that tblu permits both a0@ and a0@-, and
> gas does not implement that.


My reading of the 68000 Instruction Set Manual says that it is not
permitted which is consistent with the implementation.  But the CPU32
Reference Manual is pretty clear  in that a0@ is permitted for both
instructions but not a0@- or a0@+.  Sounds like the manual set is very
inconsistent.  It would be interesting to listen to someone at Motorola
squirm. :)

> I checked a CPU32 specific manual, and it says that both instructions
> support a0@, and neither supports a0@-.

That's my interpretation as well.

> I couldn't get any useful information from the Motorola web site.

No Surprise here.  They have a lot of stuff on their site but you can
never find what you are looking for.

> Since a0@- doesn't really make sense for these instructions, I'll
> change gas to not permit a0@-, but to permit a0@, for both.
> 
> Either way, the submitted patch is wrong, since it permits operand
> types which are not actually permitted.

Fine.  It sounds like whoover wrote the patch was not that knowledgeable
but knew there was a problem.  

Thanks.

--joel



From Ian.Dall@dsto.defence.gov.au  Wed Oct 29 05:06:00 1997
From: Ian.Dall@dsto.defence.gov.au (Ian Dall)
Date: Wed, 29 Oct 1997 05:06:00 -0000
Subject: ns32k support broken in gas 971029 snapshot (with fix)
Message-ID: <199710291305.XAA08929@sibyl.chez-dall.org.au>

Gas core dumps when trying to assemble instructions such as:

	movb _z(pc),_c(pc)

The problem is in tc-ns32k.c (convert_iif). There is code which ends up
calling frag_more with a negative argument, which causes an assertion
to fail within frag_more(). When this code last worked, it did some
fiddling of the obstack directly, which is admittedly evil.

I have done some work to clean up this code and avoid the above
problem. The patches are quite extensive, but that is mostly due to to
a general tidy up reformatting to avoid excessive line lengths.

The old code overloaded the opcode pointer under certain circumstances
to point to data in the notes obstack. This was messy. The new code
just adds those fields to the md part of the frag structure and the
fix structure. This adds to the size of the frag structure for all
targets and it may be time to make this conditional as per the comment
in as.h (but I have not done so).

Here is the proposed ChangeLog entry, diffs follow:

Mon Oct 27 21:44:30 1997  Ian Dall  <Ian.Dall@dsto.defence.gov.au>

	* write.h (struct fix): comment fx_pcrel_adjust field.

	* write.c (print_fixup): Use TC_FIX_DATA_PRINT (if defined) to
	print out MD fields of fix.

	* frags.c (frag_var, frag_variant): Use TC_FRAG_INIT macro (if
 	defined) to initialize MD fields in frag.

	* doc/internals.texi (Frags): document fr_opcode_frag and
 	fr_opcode_offset fields. Documetn TC_PCREL_ADJUST macro.

	* config/tc-ns32k.h: Add comments. Remove obsolete
 	BFD_FAST_SECTION_FILL definition, change prototypes for
 	fix_new_ns32k and fix_new_ns32k_exp to add new arguments
 	opcode_frag and opcode_offset and remove
 	pcrel_adjust. (TC_FIX_TYPE): add opcode_fragP and opcode_offset
 	fields.
	(TC_FIX_DATA_PRINT): new macro to print out TC_FIX_TYPE.
	(TC_FRAG_INIT): new macro to initialize machine dependent field in
 	frags.
	(frag_opcode_frag, frag_opcode_offset, frag_bsr): macros to access
 	MD fields in frag structure.
	(fix_im_disp, fix_bit_fixP, fix_opcode_frag, fix_opcode_offset,
 	fix_bsr): macros to access MD fields in fix structure.

	* config/tc-ns32k.c: Avoid overlength lines. Align comments.  Don't
 	use struct opcode_location as these fields are now in the frag
 	structure. (convert_iif): Call frag_more as it is needed instead
 	of trying to allocate for the whole insn. Avoid call of frag_more
 	with negative argument. (md_pcrel_adjust, md_fix_pcrel_adjust,
 	md_apply_fix, md_estimate_size_before_relax, md_pcrel_from,
 	tc_aout_fix_to_chars): use accessor macros to get md fields in fix
 	and frag structures. (fix_new_ns32k, fix_new_ns32k_exp): add new
 	arguments opcode_frag and opcode_offset and remove pcrel_adjust.
	(convert_iif, cons_fix_new_ns32k): call fix_new_ns32k,
 	fix_new_ns32k_exp with changed arguments.

	* as.h: Move fragS typdef to before struct frag definition.
	Remove ns32k frag substructure and add fr_ns32k substructure.


begin 644 gas-971029.diff.gz
M'XL("&HS5S0``V=A<RTY-S$P,CDN9&EF9@#D7'E3V\BV_]NI^R$:;M5@$]F1
MO!N&J4<(9*C*PL-P9^;E4BY9;ML*LJ31`F$8OOL[2VLS,B$D9+F78B98ZCY]
MEM\Y?;K[M"?V="KJ@24:C6<S,ZP/>H;>'."?SX[W=U^\WA>-W(<GFYN;*UM6
M?I,3\=:*1',@C,%66]_2^_#'H/>D7J\7R.1;-IM;G=Z6,>"6F\4?&L_H&9K1
MZPIZ@*3X04_`W_4G0E1"RQ.M1O.BW6@F'SU?NJ$,+F0@.@U=5,W&><-L4"O\
M7*-VO@ERAYYC!G;XY*E(?MRPU3P755=&XW"B"<>.9(@=X/=0C*5CRPLIHKD9
M"9!(X*^P`B\,ZV88RL78@3$MTQ56'`32C9PKZ",B,YC)*`*QIUX`A!9>&`EO
M"F2D,,<>$)S#DU`3OA.'Y5H8#+2FWF$M"#&,?=\+(B0G]E\=B'#NQ<Y$7'K!
MN7"]2WI.`FIB[ONF)NQ6OZL)T_'G\&'1[9]K0.7UX=$0QO0N9>!;#91QK4"9
M5*$!]W-/`HE^5X>^_?ZY6)@D5AA/IS*PW9F8!MY"C.TH\**&TM547'FQB((K
MX<6L*\\%=2]85@'D62O`;P1:#E$[I`O4@C1#*1QX"<W/02`@B+H*9!@[J*?0
M`V.@FF-_8D:27B*-!B&DJ>N@K&Z"D*^CK%#^&8/!`3FHM=H/IK;)ZD!@AHVY
M\E_\<T40P%<E(6"P'`*6VW$`:.JK`T#;:&IMHY<%`'H`/91YQ?/3EUO"CE+U
M+LP@`B^,/#$WP;5,$8*N'0FVLUU\X8&H\/("'-^+0X&B2_15I`5:E2'9,WT,
M5C)GXMQV)V%##"4:XE)8W@0(FFZ(G3:?0?R`W^C*EQ,Y%6$4Q);JA_\;;N-[
MD7\.GZZQJWBV*=Z.WTM\;`./YF0"UH*!@&:I,MIMK=TQDCB@?BXE6G4C`DN;
M#H0<RW,G=F1[KNG8?TG034.(D[D=,ML*_V.9$8!^06"Z,P03`A+ULS#/5:#S
M(;S9$-D:)"KW4+)<@Q?PCS4W`^%;@71&YN1]'$::&(?!MGI_P\%D&WK_TYZB
MDDZ'AV]>CO9>[K]1%$$3+SP4PG8M)Y[@V,!Q[#J@#Q&C#06V1M;.I?19O2'*
M-_$NW5+>""WM'F@L#0;?D<8(&F)S&HP\'X<9X8.C[?1][(;VS(4!;`)AT@K@
M&\IHNZAX>%W0-GS^%@HOA6RWJ[5[K02R_P1>;%>*X>'_[;\]&`U/CD_W3D8'
MQ[LOQ;_A=;5*\FS6_I*!-U+N0)II@$PX&P>F4T\:_72K%4[5(-AO4ER:+EDE
MA+"0=7VGGW&\)!>K"_B]PVTI)@.Y/9[-^1U@QPRD&,>V,P$E)4BA=_`O:--;
M0"R.T/J'H-U08S5!W(#<(=`2?:-AH1>(8KLCB-9$2"*O4_L#A`,)D`-Z8V\6
MA]N,94A]VCV%Y3M"-J!Y:L^>15:=0-"P5/"]]7Q%,+_5[G9D;^G+D?W.3BK,
MM^[(\]I:,Q_77KXY%2^EBS831_'8L2WQRK8PKZ/PO/#`!!,9F;83JKD3?OZ`
MN5,Y*\7^0%K2OB`?M3S_*LFY5M-F!S(=#\!_:4=S\7)WN`US.\^5%*+WWA[]
M`9[4H,D:Y@M-7`8V3J8>=\:&!P'T&'K3Z!*1<N#%+LRW$%TTT1F($XGP$$>.
M:4E1AR0">[=:D"4\ARD>&[W>%7K3,(RZT=)[&GCN;N)M!,?4A7Y]^]OHS>EK
M86P^`Y#&"+P%P13G+SF.9S-T8NY(J3/HN)F+A#^@CE/U,I7/T3%3^.**+@-W
M"_QVL!P!#P\/1OMO3HX/]X?":%4J0-F-%V/*4`10#VR)T438]I1))QV/C@__
MM7NR/\(0*IJ=+O:DN`S]%E>0-`9C<R8A"00#7A6[OM[]?;1[_'(HVB!]\O#%
M_L'NZ:N32MT@)C"<CA8X[P4RB@,WY(GAPG1BB*ISZ4*F"2$+Y\PPPB`+2G!,
M6!IAM)*@FQC3+``$C+PF<N.`P%4_"C33T"Q#DX8V,S3;T,X-;6%HGJ']:6BA
MH<5&#68"GLA`]`;\=_0.NITU,%#O"-/87O$>=;`CK)7O/4JT=H3\2`N5P.R(
MV<J&E.CL"/ON!BFA\Y7M[,5H8H?^CEBL;`*$S`^C,!Z#MB,0T%O9$O(0G#N.
M=L2?*]NDUMT1(342983"8$?$AIH`50(QW/_?4\#K:._MZZ/=D]WGAZ\.3_Z@
MN-)J:ITTKOSP\$XSJSM_5OO`_?I_$4>I?,11*O#S$5]9W23G+A]KE/>8E4TS
MGUE-[I;;K&R9=YS5]$I\9V7;@O>L)EET(&KVF2Y4-F-T^UJODU_F4<:+P^*0
M"L:0].*\0V`&Y_!\F&W=B:CJ]18$T30]IZZA93IR,E(4@`#U@HEL;.,:@R9B
M;L-O2GL'<L:=X0_<>PA@G<!Y+#=X:HBJ4>_7&-%I[ZGCF:!;QU2]8?TBP.N/
M]4;CN`>)>B@.X,^#GK!QN4ZM0:XZ+=CKZ5!%FN9BA!AF@C*,[(6)>R$+\T,:
M+&8J_4!5U1>\8@^BL"B9PA'3`:827.T8F.BK'01\@JD$3?K%_H1891,#"=`#
MC8,*_*H%)K@Y)B@NKK:FWA(-)#_";2'[P[OFV3:2<J0[`XN`%/FQJV%-$_H.
M4*)`09$#`S"L"_IZ?HG[7X,6Z(BN"GT?#S;9&(0?\1\&H++PT^]K@S1AI4F.
M!]K__6BT]^ON\?#=F=@1ZW)_?;O8X.#52;[!=+).W%SBI@'N-:2K<K5UZN"&
MJF6&4H,&V(R3Z#5<=9\>'>T?[^T.]R''YHTY!Q8:PC47DB;93<Y&3<@A7%Z\
M0_I/2V98FL.:`:91_$2@PXUZ;`>(6-@3&W<_(7E?$"L1K'.8'FW(6U$,UF=3
MJ\5,CGY#[*HS@H5IS7&VS@]NF2Y3&H/`]H7-JWP8!!=',2Y)@"),1^)H]_@D
M;(C?R@5(SA(F.;9\/_#\@#C'S@(W@:$G-+5G+MHVHX:"ST'BL928HO!N!#`2
M;2B]@<$N9(#/B#7<?2%D0I_0EY8]M=E/=X>-7W/K(=:?"]IA;I4KJ(T3TLK(
M\U$(BDJ#EF;H[20L?8\HNA>`6&6W4"1+4+0*0$SB4U!T&T")Y1Z`HHR%ST>1
M$@7WM;X"C$IWBHRN9C2[^>0(=T@+<?@D@&3>9N?E%)44LB(.%[/$DZ7/!+U#
MUXYLX)A>)6\R"BIW'(K-)(MD/H[4F8,9)4T2,=-I"7E/<TKN]1ON(>,SFEL9
MT6`ASR*[T>3+LX,]K>-*ZFII.L"M8)Y0ANI4:FY:Y\F0-[S8@,XCZGRBVAXF
M5CG,P>@`X&U&J?$4\\#S",`V0O#3P+S7;C0-S6@5$I'_3LMD&<,#3?2EK5.Z
M*:5WM5933_SH'TR#H[`?RGCBC7`A.12+R2CY;$(XP9@,7%Y7F+'0$U,02"[\
M*!7R6H<L`WYOX---L@1*%K=O7E0_:%>U2K5:_5#[^>=F[6GUJE9+XW4T]T+>
M8;<A2_FP$6)P(>.*60#1CS8-%IA=(A2(([:7+>D4$%:.&#P7L1/9OH,1:'PE
MVDB$$D,TN,F40%\0HQOB7_9?*5=J6Q'B>NRRCA7DY(R0"6/35F3#RK9(LX0L
M)^;SX]TW>[]6*D9^9V/O>/]5I=+D31-#!_6GT^.#U/^=Z+^H>E;A`_6?5ST3
M>@S]E[I#$]RAU5_>I7WQ]O3YJWWLE#T[??-B_T!D/RV>UDY(<XZ]L&%*0P7"
M*L>*'5I@T%$_QKQ"G",%D#YI,ZO!$N,I$"<'D'2$U&L,JQD75V^W$U*<;0M$
MQY`'I90@MB**EM<!.'?SD2;$'7>".<)<XJ'6%:CT`@?BV@`0!:*:._$NF2`8
M#;>\Z?SO$"*9AQ*#:6.$C)M-[+<8JO.>#C(;X4CJ$`"&]/"S`#S`XHVD-162
MT!4@_PDHHD+"Y(2>AOV3555TF1[B,S4^&54C$4RC5)-5TQH+2%;"&!*:X-DX
M")^]#^%?//C%8@V@A>M,4!/;CRE>9L<<<Y.R'%`89H)*OV^\2Y641HHG/*"P
MW7,\8XPC$J:10C-U;^4ZB7?G/(F<FZ)#"Z)#^]:FZ@^'1J9!D/P<.&9':WE,
MWA>.W/NCF+P3CDSC$S!9#D<F\S!,YN#(9)8P^5AX+(N6;;VCM8W<@6T(R8\U
M%U5`PCO]K*9RG>NT8N(9+V.GG@.+-0XP>$B*BS9!*5N"`TAZ/(=QADE6'=,E
M3J@(`;PI@F_)F"@A+C*X;BI9%T(?=T:KL84Z(.#]U]WGP[>O3D_V1T?'^P>'
MOR<)&?*P]&HK91Q(DU#PGR,@QP6-[(B-LXT:'\GK`]!#)TMY'U\/WY<22L'1
M[E#-36Z%5D9B39$0HH+ZJ7";ZAJT<*V%3\TUL2X_1-5U3;1K-?'33X*Z_R)Z
M-5(%JI;3(&C%4P^)6N$QT^S]J/X+NC]6?^P@"?%4M+>S=C8\U7.?W\/G9N[S
MQ",`7M-(BA`F1KB9Y-*ILTIN>/`*4GBZ(VCWOU+)9'_/>JNRT$3<?OI4%7>T
M`4E=O5BH])A*^XI:>R2UE6*OVP(UIGN7V-H,1Y=FX(KJ^J%[83KV1(17;@3Y
M+(3D_40!2SODZ[6$"3XE%%5=/;E)=$CK+>)-;/Q;U_6-;3[C=)Q40IE(?;=^
MC4R_H(""#O-M:<T)*LZ_3[BK&S4%HVZ/RJV2\NBO*O^W5D`I(`:ZUAX4@A'%
MNE8QNBT[4.2%X#^MFO(TDKF,E]8VYEJ>_W8ZC-0*GG@K\`5/;M1H$(%-6!IM
M*6L-VEI'+Q[=?%'F*@_EKDR5';T%W&:^19$D%P\*G/Z4BUN=,V"Z.O4SIIGK
MBA"*5:-+K+[F0_UCR$`BW*55@>'F_H.$Q4%0R1V]IW6,S"6^,-N/PG>I^@T`
M2[.9#VT)&_WMLO'H+4P8J@*BEIO$5/5$L,1P*8QH^TO)_9X=E?@FBT'"XM-2
M7+J3)*W/_+V2GR4J-"4D$5S9QNB#3-U\N'J83%].J,^4JM1RS8'6:77REKN<
M8Z%;5<W,=0.G:1L%TVOYZ4\]RM%7F;"X.ZXO`W)E>,_'4#WW]*9$=858S0&L
MTX*0T-;S]ONZDJWS7JL*ENN/(FBI2=L@>*=='@LIAF\$&UO%!\?P8"T/YEP4
M:)Z)7V`BU3=4OI9[_K/8Z"\_;A=3HNO50"_2JM,03T5_>Y78>BHV-U@:%%&_
M5D@,<`Y1I_SH>K=B7S*GW"<6MHL1EQ#6A@B1Y<6/KF@EW?>M[D?2=RG0>TVM
MT^L7$NI5X?2!,D+ZN+$*52JFASZN<Y=%O>'<A6#2`YCTVX6\]VNQ>5\^2]4[
MZ&A=0R_$$2'&@33/MY<MFD^+;T=(JJFITZ:]*LO1:".L.M8NM8GV9PUCX2JO
M:/'*<FM#_/UW7O`N/W^'SY7HA=2%W")8[M4F7])+'O\B-GH;Q50J$V68!OF5
MPKP[=K<69WAN'TCA[KS3&XW>F5CL7"LA;]:7ERDWZIB$JY6(8IH&IW$$M1%(
M*PY"F%)&CKR0.'?Q[,3Z8FYSO!8Y7"ZP*BN5XL8)@TMS$8^2(B8/3E6SQ$OC
M6[*,K_BX$YV@JQL`ID$A5GZ/8%*6+[[]&)A*.WTQ2&5YQ/HGH4M\8VPE?*]_
M%9"51;"NT=*ZN64)R0SA,BNTYE5K-IHFC(P?FIQL-.OM>`U+V+OTE*`5\G3;
M<>3L]C;&P_UP[;:*<D61>?$4MZRTM`K(=O&2KQ?DZB-O$5R>E%8,B!/]#FV,
M&&FS6_L^8`&MVRHN<K\[*V1@_5;F4)49[.E?P32E#M/L:]VVGNU(+>W&H'_^
M@P_C_2C@+=(0S\W!@.E96,9,L0$6@)!R^=9W[AQ8G6GA.:`3YG`1>7C)BS;L
M6%?Y`MB&*A?.#N!4W;"J$\M5J4ZNL`C`-X/DF+!XPD>7Y"'","6N#[M"A'#=
MJL32NDG&29C6X]J+I-:.>+FP33X_J_.%6'5,B4=Q?"<SS,6L$('M2CE)CVS)
MW#;=]I[):)1S#[_H'LG1#=?K;/K)BK?;&H#U!MF6W:=9[[Z&(YNI"HC/,5QV
MZ/@=&"YW^IE8[SZ6^TRKE?I@NZUUN^W,!U>3U-3&!0?)LO"H]J*6HV<A0.T(
MP,>3+(+R#RWC0L_!'1H(D3,^.&9#A:H&G"];NAL1!<$Q)";2@N!JPFH#&/)<
MR0?S>`]I8@83\6:XEY"@'KQUTA#/Z0!8IM]4@26=-GY?R<23(9!?6UNC]GR;
M&;_O0)@"RT6Q2BX-Z&E,QU)W9@F!M/`=V[+Q^T[H$'/"7Y50L/0\JZP3HGKA
MV9.:D'CM"MJ/Y`<_@*4I_@,*!POPZH\4@+@7D7F.Z+074@SMV7PMJZ?[J%V6
M#\MHD,;OB*)1>+48>PY:+GGJ^>IA.N5=9XENR10QD:$%"TC.JNF=DQ0KJ^)_
MOAB6S3,J_Y).*!\ZA+4T1'H/;6F4FU1'-!K%KPZD:[W<->`?`/G+J"=MW8G\
M5:BGGB7(%_>$/0-^J@J@'P/VXL>%O7A\V(N'P+YT`NA!OCQH+^V[K,XORYA9
M&C,';2I@\PEZ8,D%?J,&5BGA.K0P?W.U$P.4UUNT@3G&;XL*,ELS;:P"CK"$
M7\)4K:J6;D=S+/^@:PKF&-PKCM2=[51I2N5L'4PXL##H?QIB3^D2"_Z!&$[`
MR?R-C[#LB4=$`8C-AB)U0A5&X!'H3EB/2FF,XX%`/`R6D'H:?641UO4OXH7&
MMYSHK@7)FM"BW.10%2\AZ@^!&O@!?;<*?AV2-9?6.:N5W%PZ6$+.U/ARNOKN
M%45PEVYC@(-2)1=6S00V9").,J#2,3I(M/"7%A)9EI\&,%4X0?D*IRO)VC@Q
M/Y"IUU75=@`Y%-UY!A+J]K/2K6L%E%_QEX()O.[FQX&/!6PY%T>6_B[EB1#T
M\\^BM9TVSK<BSD;$VHZ@KTNI(;'RQH6U?PJY1"UTN0Q`$+U;]M$S52Z=:H7+
MZ"[-Y8)^#0/JF+]50EU,NY5'YJ2FH)5>X*-,CIVM^(S[J:R\KVN][++1]^+.
M*1$A'MNSDZ',SW3MA(Z5UFP^T+D30IF/?[)[)R16>_EJ__Y>7#N["_+?YN.9
MY+><73S<V\LF\YX^T'I&9VDRYU,Z[H=WAO!TAT=/S^X)&][1$C;H-,@^JZG=
M9*Z84%WQRRL@9<*L$+]&ADJ2\1OY($"0?H/8D6%6)R"HUAH'@&&R0V=U1F[!
M\TUJ\/1I=A*>U$;T#)`J5QOQ[:3*+/F%Q"LU(HF;*Y*@UDD]+=.I92\2351R
MT15/Z+84L]D&Y1&XHQG%@%I5S<%"U^LO./Q3%:XG)LD69*)=X+Z=/,%Z7-N-
MU>%A8<PQ#$GF:L$4U,J^F/3Q^5]/=C/%^I<3I=0TK2:(ECL#7@)@2CL[:DH(
MIZ?1RU(]-R<)^LPI>CF>%^%YS/7X[\N_)S?B_B)ET:R2`V526-MKM[5>Q\C9
MY2LP_R#3K):CU"C=KM;KI><N,/GB=WFJ;7Z^/PMKRC3%,?VEO3$\Z4Y#>K([
MB97D'Z+`M")%(N3+(EF\+KFF*S;5<+0K@=^/B1>B(9>QYGG:V42:?K4A?0G8
M9HY'K*94'X5O8M;@4IX/F0SF7\3&M=IV5;,#73'5Q'M-G&M4QB5=(_FCN5UL
MJW8%F3!H!Y5PI&#2@_#33ROY_T/46?DF^BR%ZZ"G]9/O<664/Z',5TFF%$&[
MS;01$>;.+M+;F,GW.8!&\.HZJ6/NT;6E2,Z`([J/#S$23V;2;XH0R66PW$VE
M4#@+L&R(_W-\_,L/DAN'M*$?J9O*6)>,+.`WS"$=@D5RAX;WI/'12,EQ%V#6
M[@,8B/76_%,00@QE$'E,-V/SHXVJ7`&9"`J)12,AM$8O;)[SDXF.?XJ52+?[
M$LXT/&^D-$75=<9T-X8[\7VGT)QF)W=YP3"3SI'U@NV2-C\5VH#<JI$R?-W@
MB-`W=*V?76?_:HB%-]EQVT<0^Q&P,ITOC-AO!-F'AK)O@-EO!-JRL-OO=/Z_
MO6_O:^/(%OP;?XJR9Q-+IB6K):$'!/MBC!/NM8$U9#(S27X:(;5`L9`TW9*!
M]?J[[WG5J[LE,&!L9^.9V-!=55UUZM2I\SY!J^$$ZB%,=(JALVF@C@&9)I-I
MX"5O=F"&+QEL]-,/"N2"'O_B0DN+R`ABK<8_^)6[_("!2R7U..00F7.4U+6>
M'F,NSR/.Y"+'A#*S(\;XJNZA>J9JQ$`#'S;HSKHC<CZ0^!6*S(1-'_<N513'
M$]0VL#+!U\8_*EKYF/4))#;1>6^T@E;3B>7[ND%E.$SUI8"6BV^-&N!;VX_]
M8_5+Q0ZBI:)"WX-!P0"AB"X5OSL!+BR@#!ZOT^'2($%A:)#$BA,Y4H@K';4N
M4-)D=LF*A^Z(.NN3)WFT,>L'&NA+FVJ-CA)_X5_R!4HG1EHM:\;F$;C=*VE7
MJU+Z;VJ^H@WP1-+%)Z_5!+['.J9^68"D5#)?#C*YJ-.L`J2L`H"'>R'#H9YK
MQ?O0+_(&4+_OOWDI;_J3^?$H*E$#NF/D_5;.>YAA2>Q])9KE,()%XEV2J"X&
MZW*V-`)4R@<!COE[(,J!^MYQ1!#R/!P4'"-=V?&H4M]_;[0ZN.V;ZO$N^3[R
MS_]R?MYZ7"Q:AT)]D@OZY7/U:(MG[KM="%(\6K>Z%^.M95MQ:F7M'?)(3UQ\
MKBBK)?(@1GWHK$9GT]-+Q>O10Z%-K6F7Y]C:&!BM\.V8IUNM9M"N6&G]JT$"
M>W3^?\6&.]KEW*/?KL.NU]T@`X:$QP\67=PC=>8?<%<>_QZX72K>;TX'OLF=
M**,T;I=R4#LP7BA=Y`:(DR^,)^=%5P?J?T?277G3V-U[J0J<DB90+_YYM%/T
M7N_]_/JU-S-G.,?3\'G.<T*A=95"*A\BQFG9&+@H/1^(-^UJZ$9,W#O,%_6[
M"Q@6/@V(?+XSD"Q>!<H\=&Y7@(A5W:`.WU>C[%N?Q!?"J/@Q'O%8/<4X:.,?
M@=GX"G\$*J3_+]DC:Q7B'%#._PE$("EHOQ[7+<,J/XTJF.-:.(^3G^0%]\:0
MOT$<14`%5E<Y$&;_[SOKVKD02PTET6`^,MG-J`?(K7"8`"+2%6.0"M\EI;#X
MY+M^$6/)'P7*D%$F+4,^CWK>\A8`)6,(J)@[+9$3.TT?#8O\L()+F!)U&S!C
MS2N=/EX7TZJ>'S(YY'QS&L^]*V6JKPPWE4P)QK<QIX[KLQZ./\^&-SIX52!V
M-3=*XXM@ASXK?R')]9#$,@#WABVYM(6PQZ4MM/EA-5#P?[8I'!!,,FB@@<7D
M6DB:"+A^Z2;8_1QRFX<;@A*&J_I)%BW>"R7<TW7)W#1^9[T82#;`]$9DSC].
MXA0`-HU'?98#M8L$:N[\LFX8C9N`A(YFO1:TU]Q@TV\:N`[*?BU0SD7I>@N@
M7D\)?MNRV-YP_-XC+&))L5K-%<=<8[X%3^K`@X.DK:&9%6_K&XZ0@ZG[0UW1
M`%5R**2CZ$V)#H9847(F]?1.*(G9<"Q#FEFDZ>.AWB_2E-YH#6MF#82?#8!4
MLYZ2CKXB2'%ZWR\-JEPD:P'=;&?I9H70-W1/[2+\I0SO(/Z==R\35>44=6Y>
MF]15:J]GG6*V,X[.5:$6J#5JTC1MBS1VUZ2B13\FJO/(&E%*NG<Y2WTMCU08
M>/XH7@EAI5(/PDH89FC:5[)PM63A)EJ+QKHA%/*0(:RL(50:35_BY$[]Q^NI
M)\>9)YH?L$^0-HMA1"OCT(7=T6L?YU4"L`(+=/X)Z#EZ&,`)6,?LPJAD&TRH
MWB=F-;15.^OTT42JQQ)QC["`(?`16>=S*[]HOX=HVHV[LTFL*$IWPVGA^$#@
MKYX#Q.(Q?JNNK;'"FC([H_,Z&HPF/8QZ19WU:&*<WG36#0DFYZ(%J"CG;`<X
M2(57-)Z06T6VJA0/0LBI.QH&C]\]D=]-U#X_%K\D=DR"*Q.;%"DF^3?.!]'#
M7V!I13D[S37`DG9*1O[\6&+O[3M"%]</-?WG*\0DM1"3/(IP?:Q27PE6Y=*B
ML-H(PK!F(ZC%[,U%2M$M>'2IX1=P<L^3R61@R"!*CQ2]IPJ^6S,L(\$H7_Q\
M:$5)'IWM/&3UP>M96U89QWB#')/1+S':8]G/-7'*QR1.WR#'=I1HXY$5(W-B
MDL)PK0(@6+/.<]\J",3OZ]&-0)&/'0W$#B>!'<Q[.B^Y'!(<=LPS/^!L\`6.
M&:*BT6@5+)*5O-L'#HGI#GKP\D!G_<YS*531[?4F<5_L^2<@FXY]UX.]R4R*
MVV+!MO,N5SZ&-N]M$`..WAM%L&&T[G]CWN'>*0C3<'BC\H,2+O2)5%T%\/^X
M=6BZ<4;<TZX$7QV/HK.R.MBVDK(?DXJF4/T*QWVBN:2NU7PSC47(LW=Z[FL=
M$DMXQB-1L5OTV7IGFE$F7_1B/X^BL4>\\3_[(?2XH#%<@:^LCL0UG?0)'#DV
M0%OK3[HB['E$OB%4Z&,6DSV"Q^%,%.QRC:S1^43IK.?37LD`QV"BGHX.P<7@
M7QIH,(RQ?/A8UST^CFS$;A]G2/LM/#OF>I^>4CF598,)",B!7Y+-XN_NVODE
MD%SD)T$^/<9<`'$,8D.9A]JE4B-1-QX-J1@#)EZCVPN90:3_("OCKF$:C#'[
MTDEI7&P3=T\P_"!OW]!M[FPN'G/>E#!K,D^WK_IS<F&A)<N,:+/.(HPJZXWF
MZ.&!+>93DW>>`B`*N`=%0=M^-(W&?;RA,=GR26)&@M5*Y6`*V!!WH!G=U'*:
MS-:=4[YN@O40@Q*=_>'A+B-;W4"V"E--4P)^/,.XZB[!I,Q)NP%:MLH7'-KN
M^++X.X_EC--5R)MS-RIO<1Y1W#67Y0".GW>#'6T$(3$+/S05;,#"Q\X9X",]
M3!P&1P"BAP=69<A&U1YR*-B&=Y;I#7HZXS.*BZ(MAAL6=I(Y'!X*G9B[P[%W
MR-'CQIF'KO?N5AZ@><%Z>1#SN;)Z&_UG/HQUPN^NVUE/2Y?E`7YIQL^ED2%`
M["5E(F]&DX3JYO*%(H.(:$U+1WQ@=Q!3"]Q4`/>J?]N:W[J:`\:1/E"Z`D\'
M:7)!F-:P'09A-;01OM_LA:%!Q]D4;G==/*"Z1>;]3:X+'L*],[1CWZ=<&3Q*
MYM[P:12EGNP"SM/AH@-"OPTO[*W!`^5<'=ZM@3?E@FO#6T_NW7'-:^.!J5*V
M[.Y8?FWP&->\.]0BVLJCT'9X9Y@^3\7;N42/"_CAS.X&[YI=45?7@U^R'PB$
M0&0+RE<1"-LJ.\U:D\'P!.D:T@6\FK!D"W,"/HK0I/1T3!C=$RF55%847][%
MC!E8%L:%%G:"9RA1^=P'5@ER!TD(O<V-X1U;WK04X#1=AZ7S.$2\:57_)XHG
M3LGL?*J4R]96*\#Q5ZM.%ARA@3B;#O[,SE$>':1WFAB2[$H4EQ_3+#>(RUQ`
M:Y^D'G!C^:Z\LU_FL<^BLP/)@0`3&-D?WW%O_#&.3%5)$BM0JI3C<-;E2AF<
MT@3],1PR++YZ]"%4DSK?I7,CV1_Y(_BDDTPZB#FD*!$G4R)`IK:'?X+$KY;+
M:M+I,S8O<AB&>0Y'$L%B3RCA^(3%;^Q/XK97OL[6A0-1++)MI.J>,A"![_F&
M!5X/`I7$Z^Y)AZA2P6\EJ1_1+)?,V>N10D:C\61^<BK`')#4EH&F@PR8P,G9
M/H,[&"Y)4RCQ%,:3\]*S0=P9P<T3=T=%IP/!8M,TV]!USK`$7=5)`G1'R'L]
MO+L1TFSHO<D"O^*N^/.!+I\.H/*C6G?3QYD2&@X"H<EAR&6KLS9Q4JW5JT[.
M5P,)KLHZ>RQ&,98J--M-1Y(%D(MA0CHO)I&N@IF\:)TIZ#)RL.P+LI!@*1E)
M/R@U%:;$O=JW'@OJV4%<B\JBL1'DK(Y/H8KCAD(0:(F/W!#CD;DP#K(#[*])
M<K<L"380MY(V,B`M5:!<N[F,%_I9=:O^KS7_U_JZB0L`80%K.Y(D,Q:(2GI4
MN#G>C3%RWH7P'ZE--H7Z;!.-$HCP;FKWL%I;`_2QU>>_+/I8O>V?&8_N$4=6
M'93UB%;!Q]<;(U$^3:JW$:F\>%<:0?S<Y#?W<[R"A:_%#ZYDWTJ\?H&NW.<N
MH5X7<V"FOW8@D"W/^8SG-B?O_P@L5J:P))$L6TFJ!*55I_-/.F6/UIU"EY/)
M!/C</VQ>C.A,\S@<B\.G<PT!V6BYL;=W`LB[6G^0MWRWN;[(`O<2S,D>?Q,0
MY>->HP4@:]>\,'A'"XT\M?#7MMP>0>7I,9RI^-+$%W]T)EFBG^@0H6<',6+\
MS'!J)?V<>UG7DQ4YV<9NY51MG=HJJD0&;0H!D%#FXRE`U`E3&<X"1_/%]"4!
M-N]2YSPT=>GL2$YW@YD+TF<5F',JYN"35WG`IKQ"S^5]()`GE%68B/ZF:KDU
M":P]B\HLO0,JX^;18FM`D?/YTDP_^(G9A(ABJ7KUGWFW;_!+.7F^@`".1Y?0
M93J-Q@DKY2C^33(L]M-\KHRP^!XGM,;UC%'%@^E1X$,M#4&!`R"[JL+4S:W(
M2W6BW'GRL\D$U\&9/6!:!L/T,`"TFC.`1K.J:<;146R)>X?`@G]*I4"1GUO5
MZ?I!+XW&T?#MS"8=*G\FO.>J&@6<['+8ZS"$?QVI9\]4^#L#`(27PNO=HZ/7
M.WL_O^D<_?-@IVCG;"+L/SJ[:TU1U68+BQC7O3P.MSZ`BPZ5&"P_\6@M,N?R
MB;O^.5LTCOW:-W+HG#.U^.R5.3)7G[=E-G'\<_WC^&<Y4XYQ?<'I<EK<XISE
M7WQM/'<V+?**BPTN#VD?T#1Q(1B[`PNA?\BKJ<79Z7-7/3P[TR13^&'J]VME
M*?&X<C2`X(+>J>]<DTAY'A0N<W[E^NN!"L-O%@#7^4Y5/;GFMZJW_E;MVM^J
MW71CS3DIF7.2QZKAGT7L6FI8.RK3DS^P?(=S"O-2@>:\-TE!_=<9AESGE-*L
M+U#)8=9=R6?L*(78?,Q%C-$22^(M!@.89R:#J#<,?)"LAF0BQH1T["/"LKFY
M0U$9&KO"C,JY0Q#"V7O+">S67<6%L<,9#6`@#$M@O986-E8T,BS5C]G6-OP)
M?Y/KU/R^4'A<N1/)<669V+1B9::5ZPF,'!N8%8A\K+A2('+<RT14SYFEW&QR
M+Q!-K(BK:ZT"XF:M44VEX+K7*\3<D)^'DIKATQ3U&M_]LE?+5PR8I=\U=X[E
M?19>"(NF4;V[:=1N,8W:;=$DAZ'[*BX=_X(XNM8]LXS]3UU!9;6]\,Y9-DSZ
M.BK_J>ZC6]XDSHM/4K(MV/3/>;GDRBNU>C,(L6#WIROJ1+2_6TT=_N*6_O-G
M8U*^C"8GPY[U>34P&/]>1KVX+7!EU.96:6%NBLHZG3,08;O]P$5SU#$<1\[Y
M@;.'!NMN8G<+#2J)&`#&O@5`61,`@*X',^:Z+:;G4<JE1"M,LB8$]!1S.@(Z
MZTS]Y*M45FIWD-*YZ#G#]-RNDK!:O+^L^PM[21%%P'=Q1`Y';D_M=5)VE)B>
MY>L#;2T:=-#OD2%_8ST+Z4JNF^1?TDW0/!XN)*T?3+`NL7J!ZHVZG,ZJ+H?+
M8<[%:%;7I2G(2_N<W(;$5U,<.M%/KXY4=(BN$]W>:2JC[-6T3>CKIQ`XZ>)2
M.7FD2=U#]V&%+`-C=+3*H7TI*\%MK3G>4"&'@K%_31YMS7Y<;%V'B!X5CH;2
MF^(3$OW4)25U^YA/.ML>A^(L:7*-^\8A28;'6'?MRA(N5A%"##W2[.L)4[WH
MO%!/=M:>B;.9Z-!M((B;Z6J;T(\;]H>#011'0%;\HL"6^GI&')8;6.K"#1%X
M)+/N"3FDD`LM$+H).TX:_VCFS"+X%KF,DH?.\:6U7`:HD-3]T<7%]"%7%^-S
MUGF/B;"[5.&$,3NB1*`D_IH^7<4)7#`?L*:EQMEM./LW@&8TP?ARTX/.9AR=
MHT?O>#*.`IE_C`ZYZ67$*.@EZ*Y)@U-/_>3XTOH,F0[6J\2X`=-%>#H?OP.:
MBTZAZ[1&T^,\LI[`FJJP(D`H,S38VS]2_]PY,GW0/NRZ%^(=-$\,6I?J92TM
MTUYRS(&2G3QD%VO)8#6=Q)@:7W3#)Q%=31>\/,(;H18*$\/39+I),@>`5;07
M-*P4$P(ENIU@H77&T5A$1<4W5:E@CY^J%_EZ7R'`G<2PK@*VH\<>,V(=U4;]
MK&^-TZ1#7N%P/@IQTCD#\@J75<>XJ!NVJVZ8M`K%8-*$K(+`BU#_>>_ESBL.
MU83S"9M";K^GY"YLHG+Q3Y82!'FOF-LU4V&R:2[)YZZ#@GFZ;J_`E!N?(SLA
M!:'!BE::TO"B:P&#2\MTLWA4V";0]SRF9(Q%(V`\_6::KY5>']EO>84I),])
MN7:*(\<)E<JPD95N++G7Q0VO;);Q1$W@+AI-NGV3%K3C.[H[;8V%,`4I"Y1-
MROJ9ZR0)\#T&*M=[UZ%S6?@>34F)5FTNZ.;L0>H-`JU[@LX;CG/<HJ;&R<QS
MEM.05,:)L6(XYY(<KM255M*0-\_)6L0$1/@N>T%ZWG"ZASZ9[@UA?^9_'8F$
M[Z:7XH$]B=])$2MD+-&!&K;6D^IU>A1]NSU]LE`LW&`Z<TZ%03+AHL^-3"\#
M7$PN)O&P=UI.WZVE1EW]D&=+PR#%G*?0ME$KIFY$2]K":]ZBYA246F&[^JDS
M@#ZAL68YJCR9A#6(?10E8*,-<EF]>0/[[3*Y[`O*6M8O[5.%+BO*7%_<4D;(
MXI[7D;0<\8H[74?&\@4K[G>5=&5%JI0<]=5)3LZY-AP'\$#DV,9NUYBRA8O@
M)!.IB+/0L"])!S6#5,Z5NWRF/]]9[FN2L-2G2%@A)XI8*!9=+16EOF^U3CG/
MC0HJ)1K=AVQT"^'HWJ6C^^.I5_&'#&+7N5[B&UB`Q[]ZS/?GY:)SO_\5,-4.
MAVAY,UJ9$^E2T&`HYO)G;G,^$MD.EDFS78`-]ANF6>2,&6$Q6^424L*G_ASO
M&O*^UB%<N8S5-\+Y6)[\+EB@7%5UO5D%EJ@=IEQKG%(S_E8X$!=%@4Z]PR><
M=!K.#60$VSK<$:F[)KLU8A_,05WEL-UT3^7(Q'EJ+?W4EP%$#:F5"WVAV6<4
MG>41:Q<:_*/E\_`WE]63V_@3N#V/V>/O4"2&&]#E+L4)/\`>.D<$_BLL;AW=
MJNO-M)W[ROV\BB^XR5Y]02AF@).+_&O-6A"NM5I.@%'F"CSM)J?JNV0=_GM$
M97A+S[`21T!5?<GE@=HSTMAO<N0VI83I8,MA3^L1D.<X(\Q3A8.WNW_?.MKI
M'.[^:T?<)U#A-HV'[U'GE4R1KYV.(KBDI;ROK33R1N+TH__,8;H@[KW9^D?G
MX.W.]N[A_AYY)LXF@](PBC`Q`?7]&W/8U-#8=@]5XX&2,.HC*A=BRW>PT,.R
MY"4PI;,##B;N<N9VT\06VT6)`/:">57\*>"(V+.A1$U/L7QR3.FDA5WEA`1,
MT*"[,S'L-=.%,DF_.HG)PU(]00P[4%@A?BP(@94W4?U*"A-,<8_!MO`<4R=B
M*,[^_Y1Y(`(%;\0#PFN$$T=^!+1&QM]4N7@.IZ,CMH;YP=::;B;(+XDU*A=K
M'&],_/,-X1#ODB#2C7"(1\@BTB?@T`.GVE,6D6Z'1+FDJ%&#>[A1;Z=J8`E,
M=3I<I3E/^)BAR(GQU^7D'D!9$Y@GQ<#.DL<<@8;<NSE()"ECX3&R*'#"!#(F
M_#0?#,Y`I$;FJ>\G2A".G<J:Z\I9U)WN?]B:2=R/8CY^(+<E#.14K@5B%[C/
M):4?F,81L?\\'D7@=PERI1EJ.`D&>%N0]_RZ.DN.5>F9&B7'_+QRP7\0T1$5
M^&DHC]6%?8U>+O(V3+W-_K#2-ZJZ_@,)C>7EZ^0HF!8#P(1+H$#YOLY=,J,,
MB`\=4B/G6.+?<^[1X_D@0%--H,:ING'P1FA.(P2:T\@4G+H#]."9&ARY/GIP
MQR4X<C5ZY`RQ!$?^1.AQ1ZB13TG:S2!L5FI^F1WLL+H*MPF,MF&>&B[,8\*T
MHND*'JR,I<+@*O@N"4"&!WC\]NB[Y+='<-]UX&K8V^ET\*=7NZ_A)U,DZ*-&
M7D9K#*AIM-;\"CCW.5>Z)Z\SWUQ88_W0L-EJW`.L;P-J(A)Q=YQ0&@BCV8XC
M=(2#4\?6':HS9VP]P_%@(JEC*.FJXHQ`9;:JP!]R_9A0DBBB$'C09^?#?G^$
M=[JN))OH("5,`M0'SB;"$M#OHQ$/P@6C(ZWC1%J`+,%\".R3SGZ2I0^V1+F=
MSI%3%IV3_U"%(;$TEZF(^HBTJ>X[6K#.?2*V9_A#'$FBA'Q9`&#/)%:%%P#,
MWNGA_/CM9`[SC8KJX7/ZGS,=)`?]3CPLPQ_.73L<$>]!10%YIJG$=W\;#@`Q
ML%8XKA4>$&4H\3A.5`Y,BO+T`S;$PR*/H0F#>;>AGXM5CI;:P6WM2`2/>A(/
ML=4'SE:"%K%AZ5F,*AH]Z`<]B.)7;EDT1K*5%3?M./P;G9&1'M.-LUA-J\L/
M+_(6@N-+5B4;+.$]+A8WKAY*K:(K<D&KIWD`UHU!IZ(;:*W^K_*;\?)^^$%5
MZ\L;BGT"6ZXM;QE=4!%!;-E<WA(Q"YNUEC>CFP';M=&9UX9_U`4X)HH^ELP_
M202'L9\'--:PD_&X.P48UJIX+GK3.:F%B[QS8D?]6S3N`XI0#ILSG7)6RQ$#
M-$I3$@0Y_F2&C*4-Y6M)WIF,-)@9B%MCLK[C:("VU0E)"V+DI@PT_%K'BS<Q
M&4BSUKB'J^*6-\7]`"7W/FJMU0+XRT@13A;1L^B,$K:O;O(8'1)*G1P0Z.Z`
M:^&-AM4*-=K9>[F[M;>RX@<OCX<]G6I--.#,GHTFYY2'NXLY[LY+T]/+9-@#
M`,/GW?J#8O7;I&0V.!52?B"5)5'6.!#B=$9)I-C54/TXF0P>$C#T1XGM/6NT
MWE$RBB$`TOG*4TG9R$GLR(1/DS,[HI&K54&XA5:D_U)PL_:F;P:`^8C8!H`Z
MI4A0P$]G)2NXF0V1O?U`W\W+N:5S%L5L39`$1C-16!Z0S3&9'[-\G4V1R$/)
M)2(#H%T71GCV3%6+&%'+IA=4M-LA%WH$P058--4Z%Z1CI%VRBT!%SA*_&OM1
ML<N(;XP9R:18^K1!<N>C<Q=NZF%7W9G2`!ZP2!/B`5N/4,H%+BNRQ%*3UWT!
M8+FW5*V-.1>6D%1!H'0*.W2?0C,NIG/)H)!V+C+I;FSVK?M#,O-QYBT0O[PG
M?^'4[7`J#YA+\`@HVA9E#"?_D4/:G_DTF^V0J"%P":R+0.E]V&?%[GM)!M%"
MV:_5-`4`[H#$R8*/<@&P$"5\A,B8<?G;%B&]YIN<)T%9<$F&.(,;.79>=\0;
M[KY\++OYJ\XS=/#)(L-]DX0[V128H[<G.+>;;XD=3>^('>^6&Z+APGEB5WU`
M77%,[_:0Y?(5;61PVPU3#XIVSFC$W(U=O`!Q3C))#STJK7.#F9+<(M^^$,X\
MD03D**&>N-7I??F*V71'?Y?]@"LW>(1-QZ"9+DX`FDS*:#Z5\03D:>Z:8JV^
M](1%5,-VQ2C:[A!N9D6,A9\!<.DO7`=R&FC^I#X1=/DHB$ZD[:;1^6'?;9-C
M54X;&_;('V.!6M?Z=J3N,/4<%PX[D$/;>#7K!!DS@.ENS>YD`#=2,*,`UG2%
MOZSSZRWGG>9LKIRV73$MH!A<8^9Y.U"MU-:":L7F!17)"T>F>8*HEKJ(S96E
MM?5IM#/K&T2.$DH4+QQ:50`27\1D],4-,X9_5ZVB#T^*V2`]X&`^9GK'5)8M
M+%$R&YYU3?Q,UV;LU\$MF.,:J]M,+P/9PF8#MK!5TUOXZ0N_[:+O;\'Y.]^H
MP,XWFSGZ#>U@]8%=HDV<H?%B9!6@XV9,Z3DI@;U*HA/2N%J/2=:XG$H.>ZY*
M@%9K=D9T')>=2;N1C^06X#G3,C.HXZ8%L@4/H-I?5ND`'%?R<+W[7*Z<#JY^
M'DHND*ME+:<'_Z"=8/.[ZOP>.?D@<[!"5X$4=U57?O@U_'VS<C$8;'B].^?=
M<:0,MB*V5RN5$#8[;.<H9>YBLR7)V8KL]C>XT\LVD/PL&9SH1IJ;QW*1K!#D
MO/98?^UI=>?[GGOH,1U\M1HV')Y/+*8Y4`^XP@$;$`+E^,7*%2<55]U"A'X)
M5A-+J[F.0)%!Q"'Y(DBPS_<O5(`$?W_NJ,Y0'J"92.+W7W1Q%!/$F6[M9(D/
M`U55R!S7U3R98_17V6G,ZX$YV,61\L_U`G;;4WXZD4U6;$.^!\JI61`L9!I'
M;W_>02[O8-N6$[(6PK+#PQ$GZ4G@-``ZA))>&RO,T',Z>"`',,N@:RHD4ATA
M/:)LA9.5?CB0XC8CSM5!A7=8AYDMAT=_K*N_2?N+HSDI%+7N8Z#;/H9;$*0Z
M=A0:L.-/:F;HJ>P9ODI<95?*[H9<\\&Q+O(<395=*Y<:654$.ZJ&N1R3F3R&
M]6H`IZ+JL/1W>RSR#T+@RI'F%PF*^.N07'5(/@6EK3'@<^&V_<)=(;ECP-#8
M_M##B8Q^1>4K4FTUA-N=E?PKI0IGIUI?RT@0,'7++"]0U*JLJC$MJF-<@VRT
M_U[O$S2P6<C]%A0X+)$0VKKNG>A",5U494'05@HJ\-P]Y2O?WLUG,S?!/.`7
MGL:.>?K79?9%+K/%I_-:N*BTQ?3%JY>=K</#G3<O7N^\E4NNT8)+KMW(2+SI
M@YI5KZ+J,TUK%FA.;5-7A9O1(N6<:F:SY:5$^*L<G95WWC__N?ZFK^Y[/.5_
MW<:??!M_GL.>?TO7VW!+VUH;[N''27Q+-[7CIGVTW=G>WSOLO-K]1V=OYY<`
M*W2-.`(6`Q4X1'V(6]GMEWL<;$#$4`3A2AXQS,#CST40;PF^?/1JK`$XFZ'G
MO'M-XF-.P37IL]4L4K@Y)I&5;%RN[O07<1,:3[C,*NJCI/`T$22J$B>J+1<O
MPB8LI%KS7./N8R&RBCM:2_XFM1JPMO::W22Q5#K7R0MR.!L!T2**/*0,@I$3
MZT11$CL7W1[F^*,8<@XY(C;&O2J$AS._'^T_9ZJXSRYX>W2-=$?J'.N<4J:-
MR\=.O>E%M4-%<V>#7,A):S`?CR\=7I+J"=";WC#NS<\P'*H7);H2\3%>26>3
MR3B12+;"\^?/U:XD?HF')Z>SYTK!L7BS4SK<W]^3TX.2[0-E#0-4X*'@VC@=
M:BZJUVJMQ?*1P:A[AKJ&."^4T'(QM`%.7+!29S\2\W+Y1@#(1\,V'+&:&U1!
M"H,X2C8$/,GUC*B.L5PNPL.=__WSSMX1$+4W!UM'6R]V7^\>_3-KF#8CI)3R
ML@2<P.JFJER$5=Z>5_O[ZG]&\SZ64!U%\>RA]@8T)B-G6VD=O/-UI"5K#BVY
MKX4:I;4[5/$.UY>[L;6P!AL;MNW&=@%'B+%#KI*>'`_Z'?:>IRL1\W%U*#A1
M5TFC14AI1&J(BY@:RR89.J>6/W%^UZ9]T7/@A-&]OF`F4507.NQ3N\3+.VT'
MA]]*SX"0HA,H>:INJN_-^+`+R67IV3&\UQO<@`57&TY]RGM:L,LZ3(OWL^+\
M+:^'L.7UIF-/$`S=?_'?G:W]GX^T!/90S7J=[F1.?(H3:R"W(@M68D[2"-\9
MCCOH-YZ*UV)9R6@G61!`J\D3S0()OHZZ%QWC<K1@;+V5[1#OQJ:C`5ZX$(RN
M[:04PU]^&?G[TP"VO]9:LRDI9%0;"9%R/9"`C=RF8S+4=73(QJ^>S\'O.H(C
MMVOAX6%G][#S<N?5[M[.2^>KA&/%H@[J>+ATBDY8Q_*&6B(QL1UV4G67N;*1
M&'J;7=*'ST6V>K.#LA5'<3Q]PJ7H7T_0F?SO8GE/UOFIA'24>I/1_&R\KBK\
M>&?<YP:6"X=OT$W;*_$5U#-<*!!1V#8;HOK-;ILCPERQ;REIZ#-LW%*P8UXF
M58I[JEQ^>M)-2NUF6*FV\<>G<-P'PY.GIOVI*N<_IR-WC?XKOP`/OP^'O=I6
M87N]7EF'G0[;[29M_H+!W4[5ZOI:<QV$%.J4>_#;@4^4)=7`T=;;'W>..EMO
MMW]:6<&KJ1OW3IF&\54$1`_SV^F&K_;?OMDZR@[`SU=6'G7+0-)+T]Y:K5K"
M,(A'EF\H2;0DR$E1/,0S`:<%+[HR55<G;9#@O!D>-^W5UN%1YW!G^VAW?P\#
M@UYSBM:_B:.";KJWWWF[\WI_&PZ8PZHX#>#=UNO.ZZT7.Z]!PGVA0DW6QSW@
M=2+U2(3F,DW:Z:@O*A#O.C3+SNED\JYP45SYL/%1JZ]U<AXZKP!MUQWP=M`F
MENQ-]Y*RH!N7BUE4>E(^]1-'?,)FW!7\5I>\7OT,X,U#[F8E:+9316.U5M1)
MB9>6V@._=;I6K'GF._7H5]F:IUD=):44EQ2S]JV3,`\'0D%#<VP/<)84TXBL
M1<K8?+#U=NO-(=!@1XW,]NI&*VBFB[W>&`"?;95.PK^LAM1YN5A'>ALXY2%.
MJQJTT]6&A>^2G(%/NIGD;\HS:'^%2.1")H<US0>/TMGKQ/3@/?%JE*2QJ*A5
MHQ(<NW=8JU[4JA(,/IZ,507^GGJ^Z>=D]TA.)W.*Q^33C7YD(]1Y)#Y5V]L_
MZ.P?;.^_W`$1M5OUB<=9OT-%P<=](!AT&%HA;JI_&.YD4[^%@_%-[_VMMC[O
M?(>52A!6C+`CP*%D2$[D/DA3)("?D6".OR'[_NOO&^[-NMWY<6=OY^WN-EZ2
M6__H'&T!&YGJ(G>X[8)J="SOI#_VP6XA2B[K*MR@V"O=120:N!!QVS!Z`]50
M_IB[>[M'-/#+K:.MPJOB2@'^*CU+]5$4Z4*.S0B#-2,YW`\,LF#`V78.WN[N
M'14PMCN0YT5"J]](Y]&?K.@_OXF][$/F"1R1:0QX.2C0.,5`/?IM[!R7S>^F
M2K!"#O/F=_W`[:__`)3@U2,5J(+,I>R,<Y!]++0A9RC3DCUYO0E_3"T!T'\4
M%2@,*06EMUL_TNX6&"H^4,Q'/Z3AD?4T_0=:@-#,N;&PG1BDJ&4EIQF*:>:E
M\_KCXJ5@8%*O!]0!DWUU>_$DT1E"QB>)G'I,F7TVP6#M>#(?BQN'P?Z<=<!_
M5C$+_[+P8QQ?>:L6C&'7>-4HW#(]C,!@86<^FODG7@.)3Y@%FK=[66)_X$![
MB:DXOXTF*7J(CS?>%Q;(1'&12#*I)R*AG:9VS1'5`5H"+O,LU=(8*@U@[;-4
MTSQ,<*G<(@S(6%V7=,YNO*@H\OKD[;=/C>G@7O_<9A>9>VSS%I0]M7;BUSRT
M2S0<_4GOJ<YDE)1GT<50M!#9%PMT'-F&.4J.5EK)L;R7:#GJB[4<]0:J.<Q]
M_U^`KF?*''-X<L"YA\2V-9J<1\FL))I3,G//;(DSZA/06<'*663UAFN.G5WX
MFC,?<%E\_>$+)32"\B<E$OJ64-HUK(-N&!_-.+U3K.29Q^)0HU[,D?_"S''_
MA9/YP-3D`5..CVY>?\EI@D-M'_Q<2J91;S@8]M1IU,74<*@1YB^+-,Z5#"XI
MJ1IM`(/.^(+='^B<$Z`?7Z@,:?[F8)K+CE8;U0#^,B*G@`\-T&>D!Z-,6SPO
M$ZSR46(F!;@4R#P<]R45-]E^N>$#)>$UP%1WB>)'_0WJ8T9D:.H1T5C<[Q/`
M9%>D;H1I[^*UTXM\VOGFZ,WC&"X)`+UP]+0-I]WI-!HC4.FFT7LQZ)X-1Y>!
M\PT@H0?;P$UVME[^]\^'1Q_YAJ+*&.QY,G'J:LTF#]`R=C;%W/_=L>LIRJL^
M@XW1&.HZDM'JB!E&"UWH6.B^[AU8#!W!T6]O%Y;<.CAZ4N[)72"_+;A?Y&WV
M4@FKZ4LEIZG<)&M+].4A.FDTK>6:.$)=@D/T")NR[1O9%B:?@'7N2[>8BHV7
M?V!?+N#57HHCSXSHFR2O*J//QH@+OSDY0[G-\5P2>O8H/?*QCMA&TM<?LE,-
MU;AB*H7D\=_:N@@S>@R#([O73<JG9:7=&+VY+J[>5=E8VEHD45Y^-Q&7AL+W
M7GLDI('RGV&:L*(+-8Q&.`,ADZS$QE9-#@@%^!=CGL5R2SOGI#*[CYT3T[`K
MQ1%</+%.#T+AOHXOQ>>'2RZ&K]4#H(9_8?BWA^%K-=BY\"\,=^"RY%K1=L6R
M^]N":T7>YEPKC?2UDM-4KI7&DFNE55T+JBV=NXUV4Q[Y'J:*E%RRF1URZNR$
M6#L0.,_8<0%*YL?)I4G:891CMN6C9X^<G!ZK[CYZ6CEXI7)T=?X''6D8!EUU
MMSC[X=_&CZR!_LK].?7`NLAT+F^OOS]Y9O+6XOU9JP1K?L)A*3Z+M&0>ZVSY
M`Q`#AM&X=TEI=XC10Q:)W$O1I`M?IN9)V?IW$.F;]C*>F4)HA"B1)U`FXY8=
MX*?).?!7XTL)D6?IX_UD]#[JFY@0HQ32@TF)$P`-K\]%M*]A?5SMVHAOQY>4
M,['L#WV+E2]`OM&,94-`&/UC#MKI5VF<JZW7ZR[.Y;6[&N'"0-(M`;U\J)X>
M#\=/DU,Q<R@SP9+:QNK#F-<CN4Q`#K;"Z&AX/)M,1F7J\`M&J<RG_:[4M,*M
M[<7#Z0Q=T'#C2!+`+*M[/[^AK4;W,DK)*@4>XFB`>9]15(*9$:+8F1UWOX*Y
MY4&Q'3:"=M7DK(EZIU*O&3_UOR9XS<#C^$R5!K']'<0W]<,/._NOU#/],'<7
M>!6PT(-X\GX(]R*E>.Z.`+?Z^#;NQI>EX_EPU'<3T291_'[8PRS:,`A!5,]2
46V+N8);>CMS%//\?@MW)(YHH`0#N
`
end


From Ian.Dall@dsto.defence.gov.au  Tue Nov  4 05:56:00 1997
From: Ian.Dall@dsto.defence.gov.au (Ian Dall)
Date: Tue, 04 Nov 1997 05:56:00 -0000
Subject: Target dependent frag fields (proposed change)
Message-ID: <199711041355.AAA14448@sibyl.chez-dall.org.au>

Following the comments in as.h, I decided to have a look at making the
fields needed for the ns32k configurable.

This turned out to not be very hard. Basically the problem is that you
would want targ-*.h to define TC_FRAG_TYPE (like TC_FIX_TYPE for the
fix structure), but the targ-*.h use the frag structure quite a bit so
it has to be defined before the targ-*.h.

The solution to to have an incomplete definition

  struct frag;

before including the targ-*.h and defer a complete definition until
afterwards.

I don't have the resources to test this for all targets, but it works
for the ns32k and looks safe for other targets.

Ian


ChangeLog Entry:


Wed Nov  5 00:00:20 1997  Ian Dall  <Ian.Dall@dsto.defence.gov.au>

	* as.h: Move struct frag definition to after targ-*.h is
 	included. Leave incomplete definition at old place. (struct frag):
 	Add TC_FRAG_TYPE analagously to TC_FIX_TYPE.

	* config/tc-ns32k.h (TC_FRAG_TYPE): Define to contain ns32k target
 	dependent frag fields. (frag_opcode_frag, frag_opcode_offset,
 	frag_bsr): change to reflect TC_FRAG_TYPE definition.

Patch:

diff -rc ../gas-build/gas/as.h ./gas/as.h
*** ../gas-build/gas/as.h	Wed Oct 29 22:57:20 1997
--- ./gas/as.h	Tue Nov  4 22:45:52 1997
***************
*** 395,472 ****
  typedef addressT relax_addressT;
  
  
! /* frags.c */
! 
! /*
!  * A code fragment (frag) is some known number of chars, followed by some
!  * unknown number of chars. Typically the unknown number of chars is an
!  * instruction address whose size is yet unknown. We always know the greatest
!  * possible size the unknown number of chars may become, and reserve that
!  * much room at the end of the frag.
!  * Once created, frags do not change address during assembly.
!  * We chain the frags in (a) forward-linked list(s). The object-file address
!  * of the 1st char of a frag is generally not known until after relax().
!  * Many things at assembly time describe an address by {object-file-address
!  * of a particular frag}+offset.
! 
!  BUG: it may be smarter to have a single pointer off to various different
!  notes for different frag kinds. See how code pans
!  */
! 
  typedef struct frag fragS;
  
- struct frag
- {
-   /* Object file address. */
-   addressT fr_address;
-   /* Chain forward; ascending address order.  Rooted in frch_root. */
-   struct frag *fr_next;
- 
-   /* (Fixed) number of chars we know we have.  May be 0. */
-   offsetT fr_fix;
-   /* (Variable) number of chars after above.  May be 0. */
-   offsetT fr_var;
-   /* For variable-length tail. */
-   struct symbol *fr_symbol;
-   /* For variable-length tail. */
-   offsetT fr_offset;
-   /* Points to opcode low addr byte, for relaxation.  */
-   char *fr_opcode;
- 
- #ifndef NO_LISTING
-   struct list_info_struct *line;
- #endif
- 
-   /* What state is my tail in? */
-   relax_stateT fr_type;
-   relax_substateT fr_subtype;
- 
-   union {
-     /* These are needed only on the NS32K machines.  But since we don't
-        include targ-cpu.h until after this structure has been defined,
-        we can't really conditionalize it.  This code should be
-        rearranged a bit to make that possible.  */
-     struct {
-       fragS *fr_opcode_fragP;
-       unsigned int fr_opcode_offset;
-       char fr_bsr;
-     } fr_ns32k;
- #ifdef USING_CGEN
-     /* Don't include this unless using CGEN to keep frag size down.  */
-     struct {
-       const struct cgen_insn *insn;
-       unsigned char opindex, opinfo;
-     } cgen;
- #endif
-   } fr_targ;
- 
-   /* Where the frag was created, or where it became a variant frag.  */
-   char *fr_file;
-   unsigned int fr_line;
- 
-   /* Data begins here.  */
-   char fr_literal[1];
- };
  
  #define SIZEOF_STRUCT_FRAG \
  ((char *)zero_address_frag.fr_literal-(char *)&zero_address_frag)
--- 395,404 ----
  typedef addressT relax_addressT;
  
  
! struct frag;			/* Complete definition after target
! 				   dependent includes */
  typedef struct frag fragS;
  
  
  #define SIZEOF_STRUCT_FRAG \
  ((char *)zero_address_frag.fr_literal-(char *)&zero_address_frag)
***************
*** 656,661 ****
--- 588,660 ----
  
  /* this one starts the chain of target dependant headers */
  #include "targ-env.h"
+ 
+ /* frags.c */
+ 
+ /*
+  * A code fragment (frag) is some known number of chars, followed by some
+  * unknown number of chars. Typically the unknown number of chars is an
+  * instruction address whose size is yet unknown. We always know the greatest
+  * possible size the unknown number of chars may become, and reserve that
+  * much room at the end of the frag.
+  * Once created, frags do not change address during assembly.
+  * We chain the frags in (a) forward-linked list(s). The object-file address
+  * of the 1st char of a frag is generally not known until after relax().
+  * Many things at assembly time describe an address by {object-file-address
+  * of a particular frag}+offset.
+ 
+  BUG: it may be smarter to have a single pointer off to various different
+  notes for different frag kinds. See how code pans
+  */
+ 
+ struct frag
+ {
+   /* Object file address. */
+   addressT fr_address;
+   /* Chain forward; ascending address order.  Rooted in frch_root. */
+   struct frag *fr_next;
+ 
+   /* (Fixed) number of chars we know we have.  May be 0. */
+   offsetT fr_fix;
+   /* (Variable) number of chars after above.  May be 0. */
+   offsetT fr_var;
+   /* For variable-length tail. */
+   struct symbol *fr_symbol;
+   /* For variable-length tail. */
+   offsetT fr_offset;
+   /* Points to opcode low addr byte, for relaxation.  */
+   char *fr_opcode;
+ 
+ #ifndef NO_LISTING
+   struct list_info_struct *line;
+ #endif
+ 
+   /* What state is my tail in? */
+   relax_stateT fr_type;
+   relax_substateT fr_subtype;
+ 
+ #ifdef TC_FRAG_TYPE
+   TC_FRAG_TYPE tc_frag_data;
+ #endif
+ 
+ #ifdef USING_CGEN
+   /* Don't include this unless using CGEN to keep frag size down.
+      Change tc file to use TC_FRAG_TYPE */
+   union {
+     struct {
+       const struct cgen_insn *insn;
+       unsigned char opindex, opinfo;
+     } cgen;
+   } fr_targ;
+ #endif
+ 
+   /* Where the frag was created, or where it became a variant frag.  */
+   char *fr_file;
+   unsigned int fr_line;
+ 
+   /* Data begins here.  */
+   char fr_literal[1];
+ };
  
  #include "struc-symbol.h"
  #include "write.h"
diff -rc ../gas-build/gas/config/tc-ns32k.h ./gas/config/tc-ns32k.h
*** ../gas-build/gas/config/tc-ns32k.h	Wed Oct 29 22:57:23 1997
--- ./gas/config/tc-ns32k.h	Mon Nov  3 23:30:53 1997
***************
*** 102,128 ****
  
  
  #define TC_FIX_DATA_PRINT(FILE, TC_FIX)					\
!   do									\
!     {									\
!       fprintf((FILE), "\nopcode_frag=%p operand offset=%d,		\
!               bsr=%d" , (TC_FIX).opcode_fragP, (TC_FIX).opcode_offset,	\
!               (TC_FIX).bsr);						\
!     }									\
!   while(0)
  
  #define TC_FRAG_INIT(X)				\
!   do						\
!      {						\
!        frag_opcode_frag(X) = NULL;		\
!        frag_opcode_offset(X) = 0;		\
!        frag_bsr(X) = 0;				\
!      }						\
!   while(0)
  
  /* Accessor macros for things which may move around */
! #define frag_opcode_frag(X) (X)->fr_targ.fr_ns32k.fr_opcode_fragP
! #define frag_opcode_offset(X) (X)->fr_targ.fr_ns32k.fr_opcode_offset
! #define frag_bsr(X) (X)->fr_targ.fr_ns32k.fr_bsr
  
  #define TC_FIX_TYPE				\
  struct						\
--- 102,135 ----
  
  
  #define TC_FIX_DATA_PRINT(FILE, TC_FIX)					\
! do									\
! {									\
!   fprintf((FILE), "\nopcode_frag=%p operand offset=%d, bsr=%d",		\
! 	  (TC_FIX).opcode_fragP, (TC_FIX).opcode_offset, (TC_FIX).bsr);	\
! }									\
! while(0)
  
  #define TC_FRAG_INIT(X)				\
! do						\
! {						\
!   frag_opcode_frag(X) = NULL;			\
!   frag_opcode_offset(X) = 0;			\
!   frag_bsr(X) = 0;				\
! }						\
! while(0)
! 
! #define TC_FRAG_TYPE				\
! struct {					\
!   fragS *fr_opcode_fragP;			\
!   unsigned int fr_opcode_offset;		\
!   char fr_bsr;					\
! }
! 
  
  /* Accessor macros for things which may move around */
! #define frag_opcode_frag(X) (X)->tc_frag_data.fr_opcode_fragP
! #define frag_opcode_offset(X) (X)->tc_frag_data.fr_opcode_offset
! #define frag_bsr(X) (X)->tc_frag_data.fr_bsr
  
  #define TC_FIX_TYPE				\
  struct						\


From devans@cygnus.com  Tue Nov  4 15:39:00 1997
From: devans@cygnus.com (Doug Evans)
Date: Tue, 04 Nov 1997 15:39:00 -0000
Subject: ANSI strings, comment style, ...
Message-ID: <199711042338.PAA03967@canuck.cygnus.com>

I'm working on adding this patch, but a few comments.

You're using ANSI C facilities to stop strings from running past
80 columns.  Someone correct me if I'm wrong but I believe
that's a no-no.  [Is it written down somewhere what, if any,
of ANSI C facilities one can use for GAS?  Should we set a timeframe for
when we'll start allowing such things?]

Also, I couldn't find a passage in the GNU coding conventions that explicitly
says so, but I think it's prefered that one write comments like this:

void
foo ()
{
  /* this is variable a, blah blah blah */
  int a;
  /* this is variable b, blah blah blah */
  int b;
  /* this is variable c, blah blah blah */
  int c;

   ...
}

rather than this:

void
foo ()
{
  int a;   /* this is variable a, blah blah blah */
  int b;   /* this is variable b, blah blah blah */
  int c;   /* this is variable c, blah blah blah */

   ...
}

[i.e. write comments on a line by themselves, above what they refer to,
rather than beside]

I've applied your commenting changes as is [the ones that reduce the
column width] but you may wish to switch over instead.

Mon Oct 27 21:44:30 1997  Ian Dall  <Ian.Dall@dsto.defence.gov.au>

	* write.h (struct fix): comment fx_pcrel_adjust field.

	* write.c (print_fixup): Use TC_FIX_DATA_PRINT (if defined) to
	print out MD fields of fix.

	* frags.c (frag_var, frag_variant): Use TC_FRAG_INIT macro (if
 	defined) to initialize MD fields in frag.

	* doc/internals.texi (Frags): document fr_opcode_frag and
 	fr_opcode_offset fields. Documetn TC_PCREL_ADJUST macro.

	* config/tc-ns32k.h: Add comments. Remove obsolete
 	BFD_FAST_SECTION_FILL definition, change prototypes for
 	fix_new_ns32k and fix_new_ns32k_exp to add new arguments
 	opcode_frag and opcode_offset and remove
 	pcrel_adjust. (TC_FIX_TYPE): add opcode_fragP and opcode_offset
 	fields.
	(TC_FIX_DATA_PRINT): new macro to print out TC_FIX_TYPE.
	(TC_FRAG_INIT): new macro to initialize machine dependent field in
 	frags.
	(frag_opcode_frag, frag_opcode_offset, frag_bsr): macros to access
 	MD fields in frag structure.
	(fix_im_disp, fix_bit_fixP, fix_opcode_frag, fix_opcode_offset,
 	fix_bsr): macros to access MD fields in fix structure.

	* config/tc-ns32k.c: Avoid overlength lines. Align comments.  Don't
 	use struct opcode_location as these fields are now in the frag
 	structure. (convert_iif): Call frag_more as it is needed instead
 	of trying to allocate for the whole insn. Avoid call of frag_more
 	with negative argument. (md_pcrel_adjust, md_fix_pcrel_adjust,
 	md_apply_fix, md_estimate_size_before_relax, md_pcrel_from,
 	tc_aout_fix_to_chars): use accessor macros to get md fields in fix
 	and frag structures. (fix_new_ns32k, fix_new_ns32k_exp): add new
 	arguments opcode_frag and opcode_offset and remove pcrel_adjust.
	(convert_iif, cons_fix_new_ns32k): call fix_new_ns32k,
 	fix_new_ns32k_exp with changed arguments.

	* as.h: Move fragS typdef to before struct frag definition.
	Remove ns32k frag substructure and add fr_ns32k substructure.


From ian@cygnus.com  Tue Nov  4 15:46:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 04 Nov 1997 15:46:00 -0000
Subject: ANSI strings, comment style, ...
References: <199711042338.PAA03967@canuck.cygnus.com>
Message-ID: <199711042346.SAA24118@subrogation.cygnus.com>

   Date: Tue, 4 Nov 1997 15:38:12 -0800
   From: Doug Evans <devans@cygnus.com>

   You're using ANSI C facilities to stop strings from running past
   80 columns.  Someone correct me if I'm wrong but I believe
   that's a no-no.  [Is it written down somewhere what, if any,
   of ANSI C facilities one can use for GAS?  Should we set a timeframe for
   when we'll start allowing such things?]

gas and the binutils are, of course, a special case, because they may
be required to bootstrap the compiler.  My inclination is to never
permit ANSI C features.  Or, to be slightly more reasonable, let's say
not for the next five years.

Ian


From ian@cygnus.com  Tue Nov  4 16:43:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 04 Nov 1997 16:43:00 -0000
Subject: ANSI strings, comment style, ...
References: <199711050040.LAA07511@hfrd015.dsto.defence.gov.au>
Message-ID: <199711050043.TAA27667@subrogation.cygnus.com>

   Date: Wed, 5 Nov 1997 11:10:31 +1030
   From: Ian Dall <Ian.Dall@dsto.defence.gov.au>

   To be honest I was not sure this was new in ANSI. We are not talking
   about cpp "#" and "##" operations. What I think we are talking about
   is writing:

		     printf("A very long string. Warning: unacceptable argument to %s instruction", insn);

   as

		     printf("A very long string."
			    "Warning: unacceptable argument to %s instruction\n",
			     insn);


Yes, that sort of string concatenation is new in ANSI.

   If this is not acceptable, what is the preferred way to do this? I'd
   sooner not make it two printf's and I think

		     printf("A very long string.\
   Warning: unacceptable argument to %s instruction\n", insn);

   Is almost as ugly as just letting the line wrap.

I say, let the line wrap.  If it really bugs you, initialize a
variable and print that.

Note that you need a space between the `printf' and the open
parenthesis in your example.  In your first example, you can, and
should, put ``insn'' on the next line.

Ian


From Ian.Dall@dsto.defence.gov.au  Tue Nov  4 16:43:00 1997
From: Ian.Dall@dsto.defence.gov.au (Ian Dall)
Date: Tue, 04 Nov 1997 16:43:00 -0000
Subject: ANSI strings, comment style, ...
References: <199711042338.PAA03967@canuck.cygnus.com> <199711042346.SAA24118@subrogation.cygnus.com> <199711042346.SAA24118@subrogation.cygnus.com>
Message-ID: <199711050040.LAA07511@hfrd015.dsto.defence.gov.au>

Ian Lance Taylor <ian@cygnus.com> writes:

  >    Date: Tue, 4 Nov 1997 15:38:12 -0800
  >    From: Doug Evans <devans@cygnus.com>

  >    You're using ANSI C facilities to stop strings from running past
  >    80 columns.  Someone correct me if I'm wrong but I believe
  >    that's a no-no.  [Is it written down somewhere what, if any,
  >    of ANSI C facilities one can use for GAS?  Should we set a timeframe for
  >    when we'll start allowing such things?]

  > gas and the binutils are, of course, a special case, because they may
  > be required to bootstrap the compiler.  My inclination is to never
  > permit ANSI C features.

To be honest I was not sure this was new in ANSI. We are not talking
about cpp "#" and "##" operations. What I think we are talking about
is writing:

                  printf("A very long string. Warning: unacceptable argument to %s instruction", insn);

as

                  printf("A very long string."
                         "Warning: unacceptable argument to %s instruction\n",
                          insn);

If this is not acceptable, what is the preferred way to do this? I'd
sooner not make it two printf's and I think

                  printf("A very long string.\
Warning: unacceptable argument to %s instruction\n", insn);

Is almost as ugly as just letting the line wrap.

Ian


From devans@cygnus.com  Tue Nov  4 17:11:00 1997
From: devans@cygnus.com (Doug Evans)
Date: Tue, 04 Nov 1997 17:11:00 -0000
Subject: Documenting new macros
Message-ID: <199711050110.RAA07607@canuck.cygnus.com>

I added docs for TC_FIX_DATA_PRINT (and TC_INIT_FIX_DATA while I was at it).
Any time a new macro is created an accompanying .texi entry should be
submitted (but there's no need to include a ChangeLog entry for it).


From devans@cygnus.com  Wed Nov  5 13:21:00 1997
From: devans@cygnus.com (Doug Evans)
Date: Wed, 05 Nov 1997 13:21:00 -0000
Subject: Target dependent frag fields (proposed change)
References: <199711041355.AAA14448.cygnus.gas2@sibyl.chez-dall.org.au>
Message-ID: <xs200vqbw3.fsf@canuck.cygnus.com>

Ian.Dall@dsto.defence.gov.au (Ian Dall) writes:
> Following the comments in as.h, I decided to have a look at making the
> fields needed for the ns32k configurable.
> 
> This turned out to not be very hard. Basically the problem is that you
> would want targ-*.h to define TC_FRAG_TYPE (like TC_FIX_TYPE for the
> fix structure), but the targ-*.h use the frag structure quite a bit so
> it has to be defined before the targ-*.h.

I checked in something along these lines and will be in the
next snapshot.


From hjl@lucon.org  Thu Nov  6 11:54:00 1997
From: hjl@lucon.org (H.J. Lu)
Date: Thu, 06 Nov 1997 11:54:00 -0000
Subject: An alpha/gas bug
Message-ID: <m0xTY06-0004ecC@ocean.lucon.org>

The recent gas has an alpha bug. I enclosed 4 files here:

1. foo.cc is the source code.
2. foo.s is compiled with -O -S on linux/alpha with egcs 971031.
3. good.o is assembled with gas in binutils 2.8.1.
4. bad.o is assembled with gas in binutils gas-971031.

I can use good.o with both libstdc++.so and libstdc++.a to generate
a working binary. But I can use bad.o only with libstdc++.a to 
generate a working binary. When I link bad.o with libstdc++.so,
I get junk output after

2 empty strings:

It seems that the return value from cout << is messed up when
libstdc++.so is used.

BTW, the asm output from -O2 works fine with gas-971031. From
what I see, binutils 2.8.1 and binutils gas-971031 treat

	lda $0,_t12basic_string2ZcZt18string_char_traits1Zc$nilRep+32

differently. binutils 2.8.1 generates

	ldq     v0,0(gp)
	lda     v0,32(v0)

and gas-971031 generates

	ldq     v0,0(gp)

I think that is a bug in gas.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---
begin 644 alpha.tar.gz
M'XL(`!L<8C0``^U:2VP;11@>D]#&6QXI%*F\!]>"!-QE=OW*HY1`^HC$0U`>
MBDJ%6:\W]E*_\*[!%2#*C0.'"G'@V$,H'#@4B8<$0JH`"0X<<N#`"?7`@6,K
M<8)#F-F=L<?CG20X301E/F4].]_^KYG]=W;V5Y8:#=T#6PL#H5PF`P&$1CZ+
M2`MAS@Q;##.7R6,BDT89(VV@+!9#1A8!B+8XK@!MS[=:$(+*R]4UY;#8TM)V
M!+2]B.M+;M6)&S"QA#/!MA-:7'_5:7ENHQY/($-'!F$\QX?UAN5K9=LV"W:C
MUL1*)7U&*Q3*]7:7*-C-:MLCQPQ6*E<;Q2JL.36[>4K#)FR?&-5;C9+E6_BZ
M577+=9C6DO/I')&W/-MU8<*$3JWIGX*>WW+K96_F!$KT"^<YX1.&2:[KOM/Q
M.:FN<\NMXXY3]\-3\H.UJZ5R$R;-Z12:2)KYR8#6]7HYN&3!9!JE]J?-"=Q.
M8NVEEE5S`C)MII)F+H6TN.>_`H-3*A3TIU-33*=F>2<AZF000B8*K&&RV6I4
M&^6V`PTM;I5*KP0VC5PJ.4W]XO.";YA%RW/M0CA^\[A]W#>FPD[!KEBM@M^R
M7-\SCMO)NEL]YC2),K9EI,S,!#:!W1>=H)_,IG&H+WNM(%2[VJ@[A<+3YC_P
MD*;FN>D*[&.+:6+?G.Y.>D8C[F:ZP1@Y&DPX4DRDD@:=*.YJ,&XTS+`?P'-*
M(IBA1A$);WJR-Y5VH^VS7CY%LJPW&85"U2L4\@WLP+%J3\W;4:-T/6*5_!DY
MX8X9>='6PEHA%XXQ5\?F!T:ZB(SCBX;1D_EOQ<)-\$`@:T\PERGA0]0N!@1Y
MS$++_;G"KD=G4K'NT*3/\&$4VV[5=^N%DE-U?&<P"B(_0P=%<IH<B/KF'O"@
MWWO`NS>`Q$J>LA9>(8EN8#1E!(M.B:T_;@FO0/'$T?GY&3AQ],GG)J%3MKW]
MICZ-=",+I_,&2AMP@BRN^Z?S:`KA-;#3=%IN#>M9U<F$MF7K?]$JZ8TMLQYB
MG?=_/I-'O?=_Q@S>_RBOWO_;@;<./W[DFEBLVX^!>\_$(N06=_3.Y^CO=2".
MVZ_O`^";?1=7?]T'P(M?CH&#G\?W?#L/P)WG]@*TO!/`WP!X\R,P]\))`+X*
M9'>`B]_=/;IZE!SC6":6@7.X_0SK+.,="6G/`?#0.5%O?!0<VAW8WC@?:0<<
M7$:W)(G/Y7NRH>]1`/\0Y0".#X_I(SRF#^_:\_U\[/2?)]^[===(;ZX`&*/G
MH_A8P`>*A3S!=6O,^P4F=$T_?YKVS]#V%]J.C?;+580^'],J!K8[>I&T'""]
MMDKYN\!M?7J/G>[)DG$=&0?@$M=?&.]=OQX?AR_U[-\A]+/X>/3RZBJ;GUGA
M.O&W0,^[$TH0;D,!63E!_VX3R#:;X/Y''GWF?L!V<8&9C:J&V]/0G6!FB#T)
M&':3!<AF!0R\-,$5?Y\#\8T8G49='.+N%Y\;46`R(Y+K75SJSTN"&R7\!#[>
MOCS(/PC"_!21$>RP6&<D]N<E]E^3\.<E_.<2_@<)?VNLGV=QDCD,/KMH7_P:
M8O+='<'0FPH`=.]4S;>*N/5;85MA9^1["N@MIVK14_+-!O2BYP&]5G**[3+0
MZPV</?1S#NCXV2*&Q7$.B]OI7.P0^#G:7A)X,17N`>&:+*)"%^45NJYJH'\=
MWTO;%.7%7$91+T?0_WP0F-3FL/KYD&N*<DQ_41@<GS\$#^-C9X2?=ZX-VSWK
M^#],.>'U!,Y2?2CPXIKP1(1-@@M4?W8=_[M!]#KR%]5_?AW]J-@)%N-A>Y$J
M[`+A>UJ\_W&)_ZE=8?N`X%!R6R,Q(I$>D:R<(Q&9')-X'5\CFI&(C)@,?B]'
MKJ_$3M1:/P*NE=@7GU;&#UJ9`H//+`')VYNX^-ES?D@BWY'PGTKX+R3\CQ+^
MME@T/^S>A-]O_!\W&"Q#6$;OY?HW<'))CK^1XR=HRS)P1.#'!/F4Q._C@E](
M^\]R/'_?%SF>S_(3'+^;XU^2Q,GX,4&^)(G3Y_HW<?(=B7W&CPGR;TCLORNQ
M?T9BG_&B_?<E]L]R?7*-W>]ECN?GX6.)7\:+\_:)Q.]/7/]F3GY%8I_Q8X+\
MSQ+[5PO*C<:6%X#6J_]D#:[^DS-(_2>-LJK^LQW8:/VG<@7K/SO7J/_`8"G^
M=]>`^'FY4O6@%2HT+FQ:61WH+&U_I^U>82'J;%,]Z`^NK^I!5_UV;0";K0?!
M*$%5#U+UH'6P7CU(_.3=:#VHL\EZT-PFZT$;U9?5@YC^L/6@#S99#SJ_R7K0
MRB;K0;MH0@Q;#ZILLAZTH.I!VUH/8OL/50^Z.C88_]9Z$`-?]^'O.U_WX;/\
M)8Z/JN^(<3)>K&M4)'%VN'Y4?4>TSWBQ7G-:8O\,UX^J[XCV&2_:_T!BGZ_[
M\/6@CSD^JKXC^F6\.&_G)7Y7N'Y4?4>TSWBQ'O2+Q/Y_%?3S:DNQ3OT'FLA@
M]1\S3_X7R$!FQE3UG^W`/K=N5]LE!QX(5_"#6H]QZ1*N5PYJFDO_AW9B4GM=
M@_3[`W9F\3EYE<`#!P;_=3=!V$[W)W&BGIC5L$++\=NM.D2SVIM;]Y]M"@H*
I"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@K_#_P-HYH%U0!0````
`
end


From rth@cygnus.com  Mon Nov 10 13:25:00 1997
From: rth@cygnus.com (Richard Henderson)
Date: Mon, 10 Nov 1997 13:25:00 -0000
Subject: An alpha/gas bug
References: <m0xTY06-0004ecC@ocean.lucon.org> <tx1u3dk4fax.fsf@cygnus.com> <tx1u3dk4fax.fsf@cygnus.com>
Message-ID: <19971110132616.52006@dot.cygnus.com>

On Mon, Nov 10, 1997 at 04:20:06PM -0500, Ken Raeburn wrote:
> > differently. binutils 2.8.1 generates
> > 
> > 	ldq     v0,0(gp)
> > 	lda     v0,32(v0)
> > 
> > and gas-971031 generates
> > 
> > 	ldq     v0,0(gp)
> > 
> 
> I'm in the middle of some gcc work right now, but I may look at this
> tomorrow if Ian or Richard don't.

The bug isn't in gas, since the relocation contains the proper offset.
My guess is the bug is in ld.so, but I havn't had a chance to verify
that; it could potentially be in ld.


r~


From raeburn@cygnus.com  Mon Nov 10 13:25:00 1997
From: raeburn@cygnus.com (Ken Raeburn)
Date: Mon, 10 Nov 1997 13:25:00 -0000
Subject: An alpha/gas bug
References: <m0xTY06-0004ecC@ocean.lucon.org>
Message-ID: <tx1u3dk4fax.fsf@cygnus.com>

Just as an aside, it's helpful to include the relocs (objdump -dr)
when including this sort of snippet in a bug report.  The instructions
alone aren't very informative without the relocs used, when they're
GP-based.  (Any interesting changes in the literal sections would be
good to know too.)

> differently. binutils 2.8.1 generates
> 
> 	ldq     v0,0(gp)
> 	lda     v0,32(v0)
> 
> and gas-971031 generates
> 
> 	ldq     v0,0(gp)
> 

I'm in the middle of some gcc work right now, but I may look at this
tomorrow if Ian or Richard don't.

Ken


From hjl@lucon.org  Mon Nov 10 13:31:00 1997
From: hjl@lucon.org (H.J. Lu)
Date: Mon, 10 Nov 1997 13:31:00 -0000
Subject: An alpha/gas bug
References: <tx1u3dk4fax.fsf@cygnus.com>
Message-ID: <m0xV1Q3-0004ecC@ocean.lucon.org>

> 
> 
> Just as an aside, it's helpful to include the relocs (objdump -dr)
> when including this sort of snippet in a bug report.  The instructions
> alone aren't very informative without the relocs used, when they're
> GP-based.  (Any interesting changes in the literal sections would be
> good to know too.)
> 

My bug report has the asm code and 2 .o files assembled by the
working and non-working as.


H.J.


From kkaempf@progis.de  Tue Nov 11 04:56:00 1997
From: kkaempf@progis.de (Klaus Kaempf)
Date: Tue, 11 Nov 1997 04:56:00 -0000
Subject: binutils-971111, sparc-unknown-linux-gnulibc1, bootstrap failure
Message-ID: <9711111254.AA29612@progis.de>

This happens on a Sparc running redhat linux 4.2 (sparc-unknown-linux-gnulibc1)

gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -DTRAD_CORE -I. -I. -I./../include -g -O2 -c trad-core.c
trad-core.c: In function `trad_unix_core_file_p':
trad-core.c:109: `PAGE_SIZE' undeclared (first use this function)
trad-core.c:109: (Each undeclared identifier is reported only once
trad-core.c:109: for each function it appears in.)
trad-core.c:179: structure has no member named `start_data'
trad-core.c:187: structure has no member named `start_stack'
trad-core.c:204: structure has no member named `u_ar0'
make[1]: *** [trad-core.lo] Error 1
make[1]: Leaving directory `/usr/local/src/gas-971111/bfd'
make: *** [all-bfd] Error 2

-- 
proGIS Software                 E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K"ampf      Fax:    0241-47067-29
Jakobstr. 117                   Voice:  0241-47067-11
D-52064 Aachen                  WWW:	http://www.progis.de



From fila@ibi.com  Tue Nov 25 01:40:00 1997
From: fila@ibi.com (Fila Kolodny)
Date: Tue, 25 Nov 1997 01:40:00 -0000
Subject: Duplicate symbols in libbfd.so
Message-ID: <Pine.A41.3.95.971125043044.54270A-100000@ibirisc2>

-----BEGIN PGP SIGNED MESSAGE-----

In the 971124 snapshot of gas2 tekhex.lo is in both BFD_LIBS and
BFD32_BACKENDS, thereby being multiply efined in libbfd.so when
- --enable-targets=all is specified.  I think that it should be removed from
one or the other.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBNHqbfnXcXr6LKdS9AQF+TAL+I2wygay27gCqbnbbW/+6kDNeTGUC2gXs
i61tH4oVoxKHuhBB4RCTSS2cfjEf6hSJjRJCuq1PIM4KDDsgzoKwv2FHmWe/NM9F
yTs9lKoSegVOhcOZ5ggHTZm4mKvW6vLe
=otOH
-----END PGP SIGNATURE-----



From fila@ibi.com  Tue Nov 25 02:55:00 1997
From: fila@ibi.com (Fila Kolodny)
Date: Tue, 25 Nov 1997 02:55:00 -0000
Subject: patches to coff-arm.c
Message-ID: <Pine.A41.3.95.971125054156.26082A-100000@ibirisc2>

-----BEGIN PGP SIGNED MESSAGE-----

Could you please include this patch in the snapshots?

Tue Nov 25 05:26:17 1997  Fila Kolodny <fila@ibi.com>

	* coff-arm.c: Make global items and routines static, with file scope 
	to allow inclusion of coff-arm.o, pe-arm.o, and pei-arm.o in the same
	executable.

diff -rup gas/bfd/coff-arm.c /home/fila/gas-971124/bfd/coff-arm.c
- --- gas/bfd/coff-arm.c	Mon Nov 24 10:31:15 1997
+++ /home/fila/gas-971124/bfd/coff-arm.c	Tue Nov 25 05:15:28 1997
@@ -726,10 +726,10 @@ arm_reloc_type_lookup(abfd,code)
 
 /* The set of global variables that mark the total size of each kind
    of glue required. */
- -long int global_thumb_glue_size = 0;
- -long int global_arm_glue_size = 0;
+static long int global_thumb_glue_size = 0;
+static long int global_arm_glue_size = 0;
 
- -bfd* bfd_of_glue_owner = 0;
+static bfd* bfd_of_glue_owner = 0;
 
 /* some typedefs for holding instructions */
 typedef unsigned long int insn32;
@@ -1459,7 +1459,7 @@ coff_arm_relocate_section (output_bfd, i
   return true;
 }
 
- -boolean
+static boolean
 arm_allocate_interworking_sections (info) 
      struct bfd_link_info *info;
 {
@@ -1620,7 +1620,7 @@ record_thumb_to_arm_glue (info, h)
   return;
 }
 
- -boolean
+static boolean
 arm_process_before_allocation (abfd, info)
      bfd *                   abfd;
      struct bfd_link_info *  info;
@@ -2050,7 +2050,7 @@ arm_get_last()
 
 /* Do the final link step.  */
 
- -boolean
+static boolean
 coff_arm_bfd_final_link (abfd, info)
      bfd *abfd;
      struct bfd_link_info *info;


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBNHqrx3XcXr6LKdS9AQGWnQL+M3baKj0IwRQBBUvgH4U94ed178kgNCeA
17+vylJBA4jCPQd+rvc0GnyUjOUJMfGpz+hsbQUVojPi20yLwEAJ/2XeFMoFqvaS
JQE1TanIerVvp0ZQ26IVoaK0xryT+gEY
=0hf5
-----END PGP SIGNATURE-----



From fila@ibi.com  Tue Nov 25 04:31:00 1997
From: fila@ibi.com (Fila Kolodny)
Date: Tue, 25 Nov 1997 04:31:00 -0000
Subject: Error in 971125 snapshot
Message-ID: <Pine.A41.3.95.971125070856.26076A-100000@ibirisc2>

It seems that there was a typo in yesterdays fix to coff-arm.c.  Instead
of COFF_WITH_PR it should be COFF_WITH_PE.



From ian@cygnus.com  Tue Nov 25 08:27:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 25 Nov 1997 08:27:00 -0000
Subject: Error in 971125 snapshot
References: <Pine.A41.3.95.971125070856.26076A-100000@ibirisc2>
Message-ID: <199711251627.LAA05220@subrogation.cygnus.com>

   Date: Tue, 25 Nov 1997 07:16:30 -0500 (EST)
   From: Fila Kolodny <fila@ibi.com>

   It seems that there was a typo in yesterdays fix to coff-arm.c.  Instead
   of COFF_WITH_PR it should be COFF_WITH_PE.

Thanks.  I fixed that.

Ian


From joel@OARcorp.com  Mon Dec  8 06:09:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 08 Dec 1997 06:09:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
Message-ID: <Pine.BSF.3.96.971208075819.25006G-100000@vespucci.advicom.net>

I ran into this error compiling gcc-2.8.0-971206 for powerpc-rtems using
binutils 2.8.1:


for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3
_ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi
_fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi
_fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _op_new
_op_vnew _new_handler _op_delete _op_vdel _bb _shtab _clear_cache
_trampoline __main _exit _ctors _eh  _pure; \
do \
  echo ${name}; \
  /usr1/rtems/work/tools_ada_311a/build-powerpc-tools/gcc/xgcc
-B/usr1/rtems/work/tools_ada_311a/build-powerpc-tools/gcc/ -O2
-DCROSS_COMPILE -DIN_GCC    -O2 -g -I./include   -g1 -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -fexceptions  -mrelocatable-lib -mno-eabi
-mstrict-align -I. -I/usr1/rtems/work/tools_ada_311a/src/gcc
-I/usr1/rtems/work/tools_ada_311a/src/gcc/config -c -DL${name} \
      /usr1/rtems/work/tools_ada_311a/src/gcc/libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  /usr1/rtems/work/tools_ada_311a/build-powerpc-tools/binutils/ar rc
tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
..... 
_eh
/tmp/cca08918.s:
Assembler messages: /tmp/cca08918.s:916: Internal error, aborting at
/usr1/rtems/work/tools_ada_311a/src/gas/config/tc-ppc.c line 4759 in
md_apply_fix3

I have cut off as much of the generated assembly as I could and still
produce the error.  The resulting .s file is below my signature.

If there is a patch for this or if I should punt 2.8.1 and move to a
snapshot, please let me know.  Thanks.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985



	.file	"libgcc2.c"

 # rs6000/powerpc options: -msdata=data -G 8
 # GNU C version 2.8.0 (powerpc-rtems) compiled by GNU C version 2.7.2.
 # options passed:  -mrelocatable-lib -mno-eabi -mstrict-align -g -g1 -O2
 # -O2 -fexceptions
 # options enabled:  -fdefer-pop -fomit-frame-pointer -fcse-follow-jumps
 # -fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
 # -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse -finline
 # -fkeep-static-consts -fcaller-saves -fpcc-struct-return
 # -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fPIC
 # -fexceptions -fsjlj-exceptions -fcommon -fverbose-asm -fgnu-linker
 # -mpowerpc -mnew-mnemonics -mno-fp-in-toc -mminimal-toc -mstrict-align
 # -mrelocatable -mrelocatable-lib -mtoc -mfull-toc -mcall-sysv
 # -msdata=data

	.section ".text"
.Ltext0:
	.align 2
	.globl __default_terminate
	.type	 __default_terminate,@function
__default_terminate:
	stwu 1,-16(1)
	mflr 0
	stw 0,20(1)
	bl abort@plt
.Lfe1:
	.size	 __default_terminate,.Lfe1-__default_terminate
.Lscope0:
	.globl __terminate_func
	.section ".sdata","aw"
	.align 2
	.type	 __terminate_func,@object
	.size	 __terminate_func,4
__terminate_func:
.LCP0:
	.long (__default_terminate)@fixup
	.section ".fixup","aw"
	.align 2
	.long	.LCP0
	.previous
	.section	".got2","aw"
.LCTOC1 = .+32768
.LC0 = .-.LCTOC1
	.long __terminate_func
	.section ".text"
	.align 2
	.globl __terminate
.LCL0:
	.long .LCTOC1-.LCF0
	.type	 __terminate,@function
__terminate:
	stwu 1,-16(1)
	mflr 0
	stw 30,8(1)
	stw 31,12(1)
	stw 0,20(1)
	bl .LCF0
.LCF0:
	mflr 30
	lwz 0,(.LCL0-.LCF0)(30)
	add 30,0,30
	lwz 9,.LC0(30)
	lwz 0,0(9)
	mtlr 0
	blrl
	lwz 0,20(1)
	mtlr 0
	lwz 30,8(1)
	lwz 31,12(1)
	addi 1,1,16
	blr
.Lfe2:
	.size	 __terminate,.Lfe2-__terminate
.Lscope1:
	.align 2
	.globl __throw_type_match
	.type	 __throw_type_match,@function
__throw_type_match:
	stwu 1,-32(1)
	mflr 0
	stw 29,20(1)
	stw 30,24(1)
	stw 31,28(1)
	stw 0,36(1)
	mr 29,5
	bl strcmp@plt
	addic 3,3,-1
	subfe 3,3,3
	and 3,29,3
	lwz 0,36(1)
	mtlr 0
	lwz 29,20(1)
	lwz 30,24(1)
	lwz 31,28(1)
	addi 1,1,32
	blr
.Lfe3:
	.size	 __throw_type_match,.Lfe3-__throw_type_match
.Lscope2:
	.align 2
	.globl __empty
	.type	 __empty,@function
__empty:
	blr
.Lfe4:
	.size	 __empty,.Lfe4-__empty
.Lscope3:
	.globl __dynamic_handler_chain
	.section ".sdata","aw"
	.align 2
	.type	 __dynamic_handler_chain,@object
	.size	 __dynamic_handler_chain,4
__dynamic_handler_chain:
.LCP1:
	.long (top_elt)@fixup
	.section ".fixup","aw"
	.align 2
	.long	.LCP1
	.previous
	.section	".got2","aw"
.LC1 = .-.LCTOC1
	.long __dynamic_handler_chain
	.section ".text"
	.align 2
	.globl __get_dynamic_handler_chain
.LCL1:
	.long .LCTOC1-.LCF1
	.type	 __get_dynamic_handler_chain,@function
__get_dynamic_handler_chain:
	stwu 1,-16(1)
	mflr 0
	stw 30,8(1)
	stw 31,12(1)
	stw 0,20(1)
	bl .LCF1
.LCF1:
	mflr 30
	lwz 0,(.LCL1-.LCF1)(30)
	add 30,0,30
	lwz 3,.LC1(30)
	lwz 0,20(1)
	mtlr 0
	lwz 30,8(1)
	lwz 31,12(1)
	addi 1,1,16
	blr
.Lfe5:
	.size	 __get_dynamic_handler_chain,.Lfe5-__get_dynamic_handler_chain
.Lscope4:
	.section	".got2","aw"
.LC2 = .-.LCTOC1
	.long .L11
.LC3 = .-.LCTOC1
	.long __eh_info
.LC4 = .-.LCTOC1
	.long top_elt
.LC5 = .-.LCTOC1
	.long __dummy
	.section ".text"
	.align 2
	.globl __sjthrow
.LCL2:
	.long .LCTOC1-.LCF2
	.type	 __sjthrow,@function
__sjthrow:
	stwu 1,-1856(1)
	mflr 0
	mfcr 12
	stfd 14,1712(1)
	stfd 15,1720(1)
	stfd 16,1728(1)
	stfd 17,1736(1)
	stfd 18,1744(1)
	stfd 19,1752(1)
	stfd 20,1760(1)
	stfd 21,1768(1)
	stfd 22,1776(1)
	stfd 23,1784(1)
	stfd 24,1792(1)
	stfd 25,1800(1)
	stfd 26,1808(1)
	stfd 27,1816(1)
	stfd 28,1824(1)
	stfd 29,1832(1)
	stfd 30,1840(1)
	stfd 31,1848(1)
	stw 14,1640(1)
	stw 15,1644(1)
	stw 16,1648(1)
	stw 17,1652(1)
	stw 18,1656(1)
	stw 19,1660(1)
	stw 20,1664(1)
	stw 21,1668(1)
	stw 22,1672(1)
	stw 23,1676(1)
	stw 24,1680(1)
	stw 25,1684(1)
	stw 26,1688(1)
	stw 27,1692(1)
	stw 28,1696(1)
	stw 29,1700(1)
	stw 30,1704(1)
	stw 31,1708(1)
	stw 0,1860(1)
	stw 12,1636(1)
	mr 31,1
	bl .LCF2
.LCF2:
	mflr 30
	lwz 0,(.LCL2-.LCF2)(30)
	add 30,0,30
	bl __get_dynamic_handler_chain@plt
	stw 3,1608(31)
	lwz 9,0(3)
	lwz 0,4(9)
	cmpwi 1,0,0
	addi 9,9,4
	stw 9,1612(31)
	bc 12,6,.L9
	addi 8,31,8
	stw 8,1616(31)
	li 0,0
	stw 0,4(8)
	mr 10,3
	lwz 0,0(10)
	stw 0,8(31)
	mr 0,8
	lwz 9,.LC2(30)
	stwu 0,8(8)
	stw 8,1620(31)
	stw 9,4(8)
	lwz 0,0(1)
	li 9,0
	stw 1,12(8)
	stw 0,8(8)
	b .L12
.L11:
	addi 31,31,-8
	bl .LCF3
.LCL3:



From ian@cygnus.com  Mon Dec  8 09:26:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 08 Dec 1997 09:26:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <Pine.BSF.3.96.971208075819.25006G-100000@vespucci.advicom.net>
Message-ID: <199712081726.MAA01373@subrogation.cygnus.com>

   Date: Mon, 8 Dec 1997 08:09:24 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   If there is a patch for this or if I should punt 2.8.1 and move to a
   snapshot, please let me know.  Thanks.

Your test case appears to work with the powerpc-eabi target in the
current sources.  The problem may have something to do with the @plt.

Ian


From joel@OARcorp.com  Mon Dec  8 11:20:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 08 Dec 1997 11:20:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <199712081726.MAA01373@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.971208130432.16589B-100000@vespucci.advicom.net>

On Mon, 8 Dec 1997, Ian Lance Taylor wrote:

>    Date: Mon, 8 Dec 1997 08:09:24 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    If there is a patch for this or if I should punt 2.8.1 and move to a
>    snapshot, please let me know.  Thanks.
> 
> Your test case appears to work with the powerpc-eabi target in the
> current sources.  The problem may have something to do with the @plt.

I have downloaded gas-971208 and am retrying this.  

I have been wondering whether the egcs and gcc 2.8 releases imply binutils
and newlib should have releases as well.  I know the as.new -> as-new
change is something which must be in sync for the one-tree build procedure
to work.

Thanks.

--joel



From ian@cygnus.com  Mon Dec  8 11:20:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 08 Dec 1997 11:20:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <Pine.BSF.3.96.971208130432.16589B-100000@vespucci.advicom.net>
Message-ID: <199712081920.OAA04767@subrogation.cygnus.com>

   Date: Mon, 8 Dec 1997 13:08:19 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   I have been wondering whether the egcs and gcc 2.8 releases imply binutils
   and newlib should have releases as well.  I know the as.new -> as-new
   change is something which must be in sync for the one-tree build procedure
   to work.

Certainly there should be a binutils release.  Unfortunately, it's a
question of available time to produce one.  I'll try to start the
process soon.

Ian


From joel@OARcorp.com  Mon Dec  8 11:32:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 08 Dec 1997 11:32:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <199712081920.OAA04767@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.971208133005.16589C-100000@vespucci.advicom.net>

On Mon, 8 Dec 1997, Ian Lance Taylor wrote:

>    Date: Mon, 8 Dec 1997 13:08:19 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    I have been wondering whether the egcs and gcc 2.8 releases imply binutils
>    and newlib should have releases as well.  I know the as.new -> as-new
>    change is something which must be in sync for the one-tree build procedure
>    to work.
> 
> Certainly there should be a binutils release.  Unfortunately, it's a
> question of available time to produce one.  I'll try to start the
> process soon.

I understand completely.  It is tough to get things to stabilize, find
time to test, and hope that the releases of multiple interdependent
packages happen close to one another.  

I am trying to get an RTEMS release out the door now.  And gcc 2.8/egcs
1.0 are the first gcc releases with RTEMS support.  

--joel




From ian@cygnus.com  Mon Dec  8 14:14:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 08 Dec 1997 14:14:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <m0xfBLb-0004ecC@ocean.lucon.org>
Message-ID: <199712082214.RAA12184@subrogation.cygnus.com>

   From: hjl@lucon.org (H.J. Lu)
   Date: Mon, 8 Dec 1997 14:08:14 -0800 (PST)

   Does soname work now? Thanks.

In what way was it broken?  As far as I know, it has worked for a
couple of years now.

Somebody did send a bug report to bug-gnu-utils about what they
described as an soname bug in the GNU linker, but, as I indicated in
my reply, the bug, if it was a bug, was actually in gcc, not in the
linker.

Ian


From hjl@lucon.org  Mon Dec  8 14:22:00 1997
From: hjl@lucon.org (H.J. Lu)
Date: Mon, 08 Dec 1997 14:22:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <199712082214.RAA12184@subrogation.cygnus.com>
Message-ID: <m0xfBYy-0004ecC@ocean.lucon.org>

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Mon, 8 Dec 1997 14:08:14 -0800 (PST)
> 
>    Does soname work now? Thanks.
> 
> In what way was it broken?  As far as I know, it has worked for a
> couple of years now.
> 

The new gas snapshot has libbfd.so.0.0.0. I'd like to see
libbfd.so.2.8.1.0.18. Unfortunately there is no easy way
to do it since I can only get libbfd.so.2.8.1 even if I
want to make a binutils 2.8.1.0.18 for Linux. If I use
libbfd.so.2.8.1, it will confuse people.


H.J.


From ian@cygnus.com  Mon Dec  8 14:38:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 08 Dec 1997 14:38:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <m0xfBYy-0004ecC@ocean.lucon.org>
Message-ID: <199712082229.RAA12229@subrogation.cygnus.com>

   From: hjl@lucon.org (H.J. Lu)
   Date: Mon, 8 Dec 1997 14:22:04 -0800 (PST)

   >    Does soname work now? Thanks.
   > 
   > In what way was it broken?  As far as I know, it has worked for a
   > couple of years now.

   The new gas snapshot has libbfd.so.0.0.0. I'd like to see
   libbfd.so.2.8.1.0.18. Unfortunately there is no easy way
   to do it since I can only get libbfd.so.2.8.1 even if I
   want to make a binutils 2.8.1.0.18 for Linux. If I use
   libbfd.so.2.8.1, it will confuse people.

Oh that.  No, that hasn't been fixed yet.  Getting the version number
to match the release number is a libtool issue.  If you figure out a
clean patch, I'll be happy to use it.

Ian


From hjl@lucon.org  Mon Dec  8 14:38:00 1997
From: hjl@lucon.org (H.J. Lu)
Date: Mon, 08 Dec 1997 14:38:00 -0000
Subject: binutils 2.8.1 problem compiling gcc-2.8.0-971206
References: <199712081920.OAA04767@subrogation.cygnus.com>
Message-ID: <m0xfBLb-0004ecC@ocean.lucon.org>

> 
>    Date: Mon, 8 Dec 1997 13:08:19 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    I have been wondering whether the egcs and gcc 2.8 releases imply binutils
>    and newlib should have releases as well.  I know the as.new -> as-new
>    change is something which must be in sync for the one-tree build procedure
>    to work.
> 
> Certainly there should be a binutils release.  Unfortunately, it's a
> question of available time to produce one.  I'll try to start the
> process soon.
> 

Does soname work now? Thanks.

-- 
H.J. Lu (hjl@gnu.org)


From joel@OARcorp.com  Thu Dec 11 07:01:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Thu, 11 Dec 1997 07:01:00 -0000
Subject: i386-go32 problem in gas-971208
Message-ID: <Pine.BSF.3.96.971211090129.22102H-100000@vespucci.advicom.net>

I recently switched from binutils 2.8.1 to gas-971208 and ran into the
following problem building for i386-go32-rtems:

Testing libgcc1.  Ignore linker warning messages.
/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/ -DCROSS_COMPILE
-DIN_GCC    -O2 -g -I./include  libgcc1-test.o -o libgcc1-test \
  -nostartfiles -nostdlib
`/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
 -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/
--print-libgcc-file-name`
/usr1/rtems/work/tools/build-i386-go32-tools/gcc/collect-ld: target
coff-go32-exe not found
collect2: ld returned 1 exit status

The same build procedure worked fine for 2.8.1.  Any ideas what broke?

Thanks.

--joel



From ian@cygnus.com  Thu Dec 11 08:35:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 11 Dec 1997 08:35:00 -0000
Subject: i386-go32 problem in gas-971208
References: <Pine.BSF.3.96.971211090129.22102H-100000@vespucci.advicom.net>
Message-ID: <199712111635.LAA27755@subrogation.cygnus.com>

   Date: Thu, 11 Dec 1997 09:01:48 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   I recently switched from binutils 2.8.1 to gas-971208 and ran into the
   following problem building for i386-go32-rtems:

   Testing libgcc1.  Ignore linker warning messages.
   /usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
   -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/ -DCROSS_COMPILE
   -DIN_GCC    -O2 -g -I./include  libgcc1-test.o -o libgcc1-test \
     -nostartfiles -nostdlib
   `/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
    -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/
   --print-libgcc-file-name`
   /usr1/rtems/work/tools/build-i386-go32-tools/gcc/collect-ld: target
   coff-go32-exe not found
   collect2: ld returned 1 exit status

   The same build procedure worked fine for 2.8.1.  Any ideas what broke?

It means that the linker tried to create a BFD of type coff-go32-exe,
but that BFD type was not defined.

The go32 code was changed around by Robert Hoehne
<robert.hoehne@Mathematik.TU-Chemnitz.DE>.  Part of that change was to
change the target name used by go32 to i386-pc-msdosdjgpp.  This
doesn't work well with the RTEMS configuration triplet of
i386-go32-rtems.

Actually, a triplet of i386-go32-rtems doesn't make much sense to me,
now that I think about it.  I'm not sure what it is supposed to mean.
i386-*-rtems should have a single object file format.  If you want to
support a different object file format, you should have a target like
i386-*-rtemself or whatever.

The snapshot isn't working because ld and bfd treat the
i386-go32-rtems target differently.

Ian


From hjl@lucon.org  Thu Dec 11 08:35:00 1997
From: hjl@lucon.org (H.J. Lu)
Date: Thu, 11 Dec 1997 08:35:00 -0000
Subject: soname patch for gas2
References: <199712082229.RAA12229@subrogation.cygnus.com>
Message-ID: <m0xgBXS-0004edC@ocean.lucon.org>

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Mon, 8 Dec 1997 14:22:04 -0800 (PST)
> 
>    >    Does soname work now? Thanks.
>    > 
>    > In what way was it broken?  As far as I know, it has worked for a
>    > couple of years now.
> 
>    The new gas snapshot has libbfd.so.0.0.0. I'd like to see
>    libbfd.so.2.8.1.0.18. Unfortunately there is no easy way
>    to do it since I can only get libbfd.so.2.8.1 even if I
>    want to make a binutils 2.8.1.0.18 for Linux. If I use
>    libbfd.so.2.8.1, it will confuse people.
> 
> Oh that.  No, that hasn't been fixed yet.  Getting the version number
> to match the release number is a libtool issue.  If you figure out a
> clean patch, I'll be happy to use it.
> 
> Ian
> 

Here is the patch. I need extension for Linux since I have to make
binutils 2.8.x.0.x for Linux. Otherwise, I have to use 2.8.x. It will
be quite confusing.

BTW, bfd/VERINFO doesn't have to be updated as often as VERSION.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
--
Thu Dec 11 08:22:42 1997  H.J. Lu  (hjl@gnu.org)

	* ltmain.sh (extension): New. Set from $vinfo.
	(versuffix): Add $extension for Linux.

Thu Dec 11 08:22:42 1997  H.J. Lu  (hjl@gnu.org)

	* bfd/Makefile.am (libbfd_la_LDFLAGS): New.
	(config.status): Depend on $(srcdir)/VERINFO.

	* bfd/configure.in (VERINFO): Substitute it.

	* bfd/VERINFO: New.

Thu Dec 11 08:22:42 1997  H.J. Lu  (hjl@gnu.org)

	* opcodes/Makefile.am (libopcodes_la_LDFLAGS): New.
	(config.status): Depend on $(srcdir)/../bfd/VERINFO.

	* opcodes/configure.in (VERINFO): Substitute it.

Index: ltmain.sh
===================================================================
RCS file: /home/work/cvs/gnu/binutils/ltmain.sh,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 ltmain.sh
--- ltmain.sh	1997/11/18 17:24:56	1.1.1.2
+++ ltmain.sh	1997/12/11 09:06:52
@@ -609,6 +609,7 @@
       current=0
       revision=0
       age=0
+      extension=
 
       if test -n "$objs"; then
 	echo "$progname: cannot build libtool library \`$output' from non-libtool objects:$objs" 2>&1
@@ -631,7 +632,7 @@
       set dummy $vinfo
       IFS="$save_ifs"
 
-      if test -n "$5"; then
+      if test -n "$6"; then
         echo "$progname: too many parameters to \`-version-info'" 1>&2
 	echo "$help" 1>&2
 	exit 1
@@ -640,6 +641,7 @@
       test -n "$2" && current="$2"
       test -n "$3" && revision="$3"
       test -n "$4" && age="$4"
+      test -n "$5" && extension="$5"
 
       # Check that each of the things are valid numbers.
       case "$current" in
@@ -683,7 +685,11 @@
       linux)
 	version_vars="$version_vars major versuffix"
 	major=`expr $current - $age`
-	versuffix="$major.$age.$revision"
+	if test -n "$extension"; then
+	  versuffix="$major.$age.$revision.$extension"
+	else
+	  versuffix="$major.$age.$revision"
+	fi
 	;;
 
       osf)
Index: bfd/Makefile.am
===================================================================
RCS file: /home/work/cvs/gnu/binutils/bfd/Makefile.am,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.am
--- bfd/Makefile.am	1997/10/25 21:56:17	1.1.1.1
+++ bfd/Makefile.am	1997/12/11 16:01:42
@@ -461,6 +463,9 @@
 	$(INSTALL_DATA) $(INCDIR)/ansidecl.h $(includedir)/ansidecl.h
 	$(INSTALL_DATA) $(INCDIR)/bfdlink.h $(includedir)/bfdlink.h
 
+libbfd_la_LDFLAGS=-version-info @VERINFO@
+config.status: $(srcdir)/VERINFO
+
 # Have to get rid of .dep1 here so that "$?" later includes all of $(CFILES).
 .dep: dep.sed $(CFILES) $(HFILES) bfd.h
 	rm -f .dep1
Index: bfd/configure.in
===================================================================
RCS file: /home/work/cvs/gnu/binutils/bfd/configure.in,v
retrieving revision 1.1.1.34
diff -u -r1.1.1.34 configure.in
--- bfd/configure.in	1997/11/18 17:27:05	1.1.1.34
+++ bfd/configure.in	1997/12/11 16:15:34
@@ -584,6 +585,22 @@
 AC_SUBST(all_backends)
 AC_SUBST(bfd_backends)
 AC_SUBST(bfd_machines)
+
+verinfo=`cat ${srcdir}/VERINFO`
+IFS="${IFS=	}"; save_ifs="$IFS"; IFS='.'
+set dummy $verinfo
+IFS="$save_ifs"
+
+test -n "$2" && major=$2
+test -n "$3" && minor=$3
+test -n "$4" && patch=$4
+test -n "$5" && extension="$5"
+test -n "$6" && extension="$extension.$6"
+test -n "$7" && extension="$extension.$7"
+
+VERINFO=`expr $major + $minor`:$patch:$minor
+test -n "$extension" && VERINFO=$VERINFO:$extension
+AC_SUBST(VERINFO)
 
 tdefaults=""
 test -n "${defvec}" && tdefaults="${tdefaults} -DDEFAULT_VECTOR=${defvec}"
Index: opcodes/Makefile.am
===================================================================
RCS file: /home/work/cvs/gnu/binutils/opcodes/Makefile.am,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.am
--- opcodes/Makefile.am	1997/10/25 21:56:52	1.1.1.1
+++ opcodes/Makefile.am	1997/12/11 16:01:48
@@ -127,6 +127,8 @@
 
 CLEANFILES = libopcodes.a stamp-lib dep.sed .dep .dep1
 
+libopcodes_la_LDFLAGS = -version-info @VERINFO@
+config.status: $(srcdir)/../bfd/VERINFO
 
 # This dependency stuff is copied from BFD.
 
Index: opcodes/configure.in
===================================================================
RCS file: /home/work/cvs/gnu/binutils/opcodes/configure.in,v
retrieving revision 1.1.1.20
diff -u -r1.1.1.20 configure.in
--- opcodes/configure.in	1997/11/18 17:28:46	1.1.1.20
+++ opcodes/configure.in	1997/12/11 16:15:14
@@ -172,4 +172,20 @@
 AC_SUBST(archdefs)
 AC_SUBST(BFD_MACHINES)
 
+verinfo=`cat ${srcdir}/../bfd/VERINFO`
+IFS="${IFS=	}"; save_ifs="$IFS"; IFS='.'
+set dummy $verinfo
+IFS="$save_ifs"
+
+test -n "$2" && major=$2
+test -n "$3" && minor=$3
+test -n "$4" && patch=$4
+test -n "$5" && extension="$5"
+test -n "$6" && extension="$extension.$6"
+test -n "$7" && extension="$extension.$7"
+
+VERINFO=`expr $major + $minor`:$patch:$minor
+test -n "$extension" && VERINFO=$VERINFO:$extension
+AC_SUBST(VERINFO)
+
 AC_OUTPUT(Makefile)
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ bfd/VERINFO	Thu Dec 11 07:35:19 1997
@@ -0,0 +1 @@
+2.8.1.0.18


From joel@OARcorp.com  Thu Dec 11 09:00:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Thu, 11 Dec 1997 09:00:00 -0000
Subject: i386-go32 problem in gas-971208
References: <199712111635.LAA27755@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.971211105340.22102I-100000@vespucci.advicom.net>

On Thu, 11 Dec 1997, Ian Lance Taylor wrote:

> 
> The go32 code was changed around by Robert Hoehne
> <robert.hoehne@Mathematik.TU-Chemnitz.DE>.  Part of that change was to
> change the target name used by go32 to i386-pc-msdosdjgpp.  This
> doesn't work well with the RTEMS configuration triplet of
> i386-go32-rtems.

Got it.  It is compiling OK now.

> Actually, a triplet of i386-go32-rtems doesn't make much sense to me,
> now that I think about it.  I'm not sure what it is supposed to mean.
> i386-*-rtems should have a single object file format.  If you want to
> support a different object file format, you should have a target like
> i386-*-rtemself or whatever.

RTEMS has a bunch of what I call "normal" configurations and a handful of
oddities.  It is the oddities I have trouble naming.

i386-go32-rtems is based on  djgpp v1 (yes old) and uses the go32 dos
extender to go into protected mode and kick off the rtems application.  It
requires slightly different newlib configuration and crt0.o as well as
some support libraries from the djgpp distribution.  This toolset
configuration is subtly different from the vanilla embedded i386-rtems
configuration.  I really do not know what this one should be named.

This ignores the harder rtems configurations like the ports to unix
(solaris, linux, and hpux) where you can test rtems applications without
a cpu simulator or real hw. :)

--joel



From joel@OARcorp.com  Mon Dec 15 13:03:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 15 Dec 1997 13:03:00 -0000
Subject: i386-go32
Message-ID: <Pine.BSF.3.96.971215145724.26609C-100000@vespucci.advicom.net>

Whether or not the name is right, it still does not work in gas-971208 but
did in binutils 2.8.1.  I checked the i386-go32 configuration against
i386-go32-rtems and did not spot anything.  I have tracked the problem
down and it appears that the BFD vector is somehow misspecified.  I have
grep'ed all the configuration files but do not see the problem.  gas
prints a fatal error message because it can't find the target vector.  I
traced it with gdb and found: 

bfd_openw (filename=0x80793b5 "a.out", target=0x8082bc4 "coff-go32")
    at ../../src/bfd/opncls.c:348
348       bfd_set_error (bfd_error_system_call);
(gdb) n
353       nbfd = _bfd_new_bfd ();
(gdb) 
354       if (nbfd == NULL)
(gdb) 
357       target_vec = bfd_find_target (target, nbfd);
(gdb) s
bfd_find_target (target_name=0x8082bc4 "coff-go32", abfd=0x80e9080)
    at ../../src/bfd/targets.c:958
958       if (target_name != NULL)
(gdb) s
959         targname = target_name;
(gdb) n
964       if (targname == NULL || strcmp (targname, "default") == 0)
(gdb) 
974       abfd->target_defaulted = false;
(gdb) 
976       target = find_target (targname);
(gdb) 
977       if (target == NULL)
(gdb) 
978         return NULL;
(gdb) 
982     }
(gdb) 
bfd_openw (filename=0x80793b5 "a.out", target=0x8082bc4 "coff-go32")
    at ../../src/bfd/opncls.c:358
358       if (target_vec == NULL)
(gdb) 
371           objalloc_free ((struct objalloc *) nbfd->memory);
(gdb) 
372           free (nbfd);
(gdb) 
373           return NULL;
(gdb) 
377     }
(gdb) 
write_object_file () at ../../src/gas/config/obj-coff.c:3128
3128      if (abfd == 0)
(gdb) 
3130          as_perror ("FATAL: Can't create %s", out_file_name);


What do I have wrong in one of the configuration files?

Thanks.

--joel



From ian@cygnus.com  Mon Dec 15 13:08:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 15 Dec 1997 13:08:00 -0000
Subject: i386-go32
References: <Pine.BSF.3.96.971215145724.26609C-100000@vespucci.advicom.net>
Message-ID: <199712152108.QAA23495@subrogation.cygnus.com>

   Date: Mon, 15 Dec 1997 15:03:43 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   Whether or not the name is right, it still does not work in gas-971208 but
   did in binutils 2.8.1.

Sounds like you are hitting a bug, but I don't know what the problem
is.

The coff-go32 should be defined by compiling bfd/coff-go32.c.  That
should be included if go32coff_vec is in the list of supported
targets.  go32coff_vec is the default target for the i386-go32
configuration.

Ian


From joel@OARcorp.com  Sat Dec 20 11:00:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Sat, 20 Dec 1997 11:00:00 -0000
Subject: gas-971208 mips64orion-rtems internal error
Message-ID: <Pine.BSF.3.96.971220124850.2016I-100000@vespucci.advicom.net>

The public domain floating point test paranoia when compiled by egcs 1.0
generates code which causes an internal error in gas.  I have cut the code
down to the following:

        .file   1 "p1.c"

 # -G value = 8, Cpu = 4650, ISA = 3
 # GNU C version egcs-2.90.21 971202 (egcs-1.00 release)
(mips64orion-rtems) compiled by GNU C version 2.7.2.
 # options passed:  -mcpu=4650
 # options enabled:  -fpeephole -ffunction-cse -fkeep-static-consts
 # -fpcc-struct-return -fcommon -fverbose-asm -fgnu-linker
-fargument-alias
 # -mgas -mfp64 -mgp64 -meb -mcpu=4650

gcc2_compiled.:
__gnu_compiled_c:
        .globl  One
        .align  3
One:
        .word   0x3ff00000              # 1
        .word   0x00000000
        .globl  paranoia
        .ent    paranoia
paranoia:
        .frame  $fp,72,$31              # vars= 8, regs= 3/1, args= 32,
extra= 0
        .mask   0xc0010000,-16
        .fmask  0x00100000,-8
        s.d     $f0,One

which when assembled as follows:

mips64orion-rtems-as -mcpu=4650 -v p1.s

generates this error message:

p1.s: Assembler messages:
p1.s:23: Internal error!
Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
2365.
Please report this bug.

This file assembles with a warning about the missing ".end or .bend" with
binutils 2.8.1.

Thanks.

--joel 
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985




From joel@OARcorp.com  Mon Dec 22 08:47:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 22 Dec 1997 08:47:00 -0000
Subject: patch for i386-go32-rtems in gas-971208 
Message-ID: <Pine.BSF.3.96.971222104422.23375H-100000@vespucci.advicom.net>

With the patch below my signature, i386-go32-rtems works again in
gas-971208 just as in binutils 2.8.1.

--joel

Mon Mar 31 16:31:04 1997  Joel Sherrill  <joel@oarcorp.com>

        * bfd/config.bfd (i[3456]86*-go32-rtems*): Fix to be the same
          as i[3456]86-go32.
        * gas/configure.in (i386*-go32-rtems*): Fix to be the same 
          as i[3456]86-go32.

diff -r -c gas-971208-orig/bfd/config.bfd gas-971208/bfd/config.bfd
*** gas-971208-orig/bfd/config.bfd	Mon Dec  8 03:18:59 1997
--- gas-971208/bfd/config.bfd	Sat Dec 20 14:21:49 1997
***************
*** 152,158 ****
      targ_defvec=bfd_elf32_i386_vec
      targ_selvecs=i386coff_vec
      ;;
!   i[3456]86-*-msdosdjgpp* | i[3456]*-*-go32*)
      targ_defvec=go32coff_vec
      targ_selvecs="go32stubbedcoff_vec i386aout_vec"
      ;;
--- 152,158 ----
      targ_defvec=bfd_elf32_i386_vec
      targ_selvecs=i386coff_vec
      ;;
!   i[3456]86-*-msdosdjgpp* | i[3456]*-*-go32* | i[3456]86-go32-rtems* )
      targ_defvec=go32coff_vec
      targ_selvecs="go32stubbedcoff_vec i386aout_vec"
      ;;
diff -r -c gas-971208-orig/gas/configure.in gas-971208/gas/configure.in
*** gas-971208-orig/gas/configure.in	Mon Dec  8 03:30:17 1997
--- gas-971208/gas/configure.in	Mon Dec 22 10:40:41 1997
***************
*** 167,173 ****
        i386-*-coff | i386-*-sysv* | i386-*-sco* | i386-*-isc*)
  			    fmt=coff ;;
        i386-*-vsta)          fmt=aout ;;
!       i386-*-msdosdjgpp* | i386-*-go32*)
  			    fmt=coff em=go32;;
        i386-*-rtems*)        fmt=coff ;;
        i386-*-gnu*)          fmt=elf ;;
--- 167,173 ----
        i386-*-coff | i386-*-sysv* | i386-*-sco* | i386-*-isc*)
  			    fmt=coff ;;
        i386-*-vsta)          fmt=aout ;;
!       i386-*-msdosdjgpp* | i386-*-go32* | i386-go32-rtems*)
  			    fmt=coff em=go32;;
        i386-*-rtems*)        fmt=coff ;;
        i386-*-gnu*)          fmt=elf ;;




From ian@cygnus.com  Mon Dec 22 09:19:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 22 Dec 1997 09:19:00 -0000
Subject: gas-971208 mips64orion-rtems internal error
References: <Pine.BSF.3.96.971220124850.2016I-100000@vespucci.advicom.net>
Message-ID: <199712221719.MAA21659@subrogation.cygnus.com>

   Date: Sat, 20 Dec 1997 13:00:40 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

	   s.d     $f0,One

   which when assembled as follows:

   mips64orion-rtems-as -mcpu=4650 -v p1.s

   generates this error message:

   p1.s: Assembler messages:
   p1.s:23: Internal error!
   Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
   2365.
   Please report this bug.

Interesting.  Reporting the error in this manner is clearly a bug in
gas.

However, as far as I can tell, the input is not valid for the 4650.
The 4650 has only single precision floating point, which means that it
can not support the s.d instruction for a floating point register.  It
doesn't make any sense.

So I think there must be a compiler bug here as well.

I'll fix the bug in the assembler to report the error in a more
coherent fashion.

Ian


From joel@OARcorp.com  Mon Dec 22 09:27:00 1997
From: joel@OARcorp.com (Joel Sherrill)
Date: Mon, 22 Dec 1997 09:27:00 -0000
Subject: gas-971208 mips64orion-rtems internal error
References: <199712221719.MAA21659@subrogation.cygnus.com>
Message-ID: <Pine.BSF.3.96.971222112434.23375I-100000@vespucci.advicom.net>

On Mon, 22 Dec 1997, Ian Lance Taylor wrote:

>    generates this error message:
> 
>    p1.s: Assembler messages:
>    p1.s:23: Internal error!
>    Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
>    2365.
>    Please report this bug.
> 
> Interesting.  Reporting the error in this manner is clearly a bug in
> gas.
> 
> However, as far as I can tell, the input is not valid for the 4650.
> The 4650 has only single precision floating point, which means that it
> can not support the s.d instruction for a floating point register.  It
> doesn't make any sense.
> 
> So I think there must be a compiler bug here as well.
> 
> I'll fix the bug in the assembler to report the error in a more
> coherent fashion.

Thanks.  This certainly turned out to be more interesting than I
expected. :)

Should I just report this to the egcs list then along with the original
offensive C program  Is there something I can do to help make this one
easier to find?  It seems pretty weird.

--joel




From ian@cygnus.com  Mon Dec 22 09:30:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 22 Dec 1997 09:30:00 -0000
Subject: gas-971208 mips64orion-rtems internal error
References: <Pine.BSF.3.96.971222112434.23375I-100000@vespucci.advicom.net>
Message-ID: <199712221730.MAA21675@subrogation.cygnus.com>

   Date: Mon, 22 Dec 1997 11:27:44 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   Should I just report this to the egcs list then along with the original
   offensive C program

Yeah, I guess so.

   Is there something I can do to help make this one
   easier to find?  It seems pretty weird.

It's probably pretty easy to fix.  There's probably just a missing
TARGET_DOUBLE_FLOAT somewhere in mips.md or mips.c.

The 4650 is not a particularly common chip, so it's quite plausible
that changes to the MIPS code have introduced bugs in the 4650
support.

It's also possible that my analysis is wrong, although it seems right
to me.

Ian


From koop@koop.inka.de  Mon Dec 29 10:17:00 1997
From: koop@koop.inka.de (Felix A. Koop)
Date: Mon, 29 Dec 1997 10:17:00 -0000
Subject: no more snapshots?
Message-ID: <Pine.LNX.3.95.971229191817.695B-100000@koop.koop.inka.de>

Hi,

the latest snapshot on the ftp server is 971215. Did the location move or
do you only have some problems with the SW?

Greetings

Felix A. Koop
koop@koop.inka.de



From ian@cygnus.com  Mon Dec 29 10:27:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 29 Dec 1997 10:27:00 -0000
Subject: no more snapshots?
References: <Pine.LNX.3.95.971229191817.695B-100000@koop.koop.inka.de>
Message-ID: <199712291827.NAA24678@subrogation.cygnus.com>

   Date: Mon, 29 Dec 1997 19:20:02 +0100 (MET)
   From: "Felix A. Koop" <koop@koop.inka.de>

   the latest snapshot on the ftp server is 971215. Did the location move or
   do you only have some problems with the SW?

We've been having various problems, which we've been fixing one by
one.  All the known problems have been fixed, and perhaps tonight's
snapshot will work.

Ian


From phdm@macqel.be  Mon Dec 29 19:09:00 1997
From: phdm@macqel.be (Philippe De Muyter)
Date: Mon, 29 Dec 1997 19:09:00 -0000
Subject: why is an archive member linked in ?
Message-ID: <199712300309.EAA31445@mail.macqel.be>

I need to answer the following ld-related question : why is some specific
archive-member linked in ?  Is there a gld option available 
or some other more intricated way  to answer that question ?

In the specific case I encountered, removing the module from the archive
made my link command succeed, while with the module in the archive my
link command failed because of some unresolved symbols in the module
that got linked in.

Thanks in advance

Philippe De Muyter


From dj@delorie.com  Mon Dec 29 19:24:00 1997
From: dj@delorie.com (DJ Delorie)
Date: Mon, 29 Dec 1997 19:24:00 -0000
Subject: why is an archive member linked in ?
References: <199712300309.EAA31445@mail.macqel.be>
Message-ID: <199712300324.WAA23012@delorie.com>

> In the specific case I encountered, removing the module from the archive
> made my link command succeed, while with the module in the archive my
> link command failed because of some unresolved symbols in the module
> that got linked in.

Sometimes, there might be more than one object that resolves a
specific symbol.  If you take one out, the other gets used, and that
changes everything.

For example, DJGPP has two math libraries.  One (libm.a) has a
complete set of conforming (but slightly slower) functions, and the
other (in libc.a) is smaller and faster, but less complete and less
conforming.  If you link in libm.a, you get that set, but if you leave
it out, the ones in libc.a get used.


From phdm@macqel.be  Mon Dec 29 20:01:00 1997
From: phdm@macqel.be (Philippe De Muyter)
Date: Mon, 29 Dec 1997 20:01:00 -0000
Subject: why is an archive member linked in ?
References: <199712300324.WAA23012@delorie.com>
Message-ID: <199712300401.FAA31778@mail.macqel.be>

> 
> 
> > In the specific case I encountered, removing the module from the archive
> > made my link command succeed, while with the module in the archive my
> > link command failed because of some unresolved symbols in the module
> > that got linked in.
> 
> Sometimes, there might be more than one object that resolves a
> specific symbol.  If you take one out, the other gets used, and that
> changes everything.
> 
> For example, DJGPP has two math libraries.  One (libm.a) has a
> complete set of conforming (but slightly slower) functions, and the
> other (in libc.a) is smaller and faster, but less complete and less
> conforming.  If you link in libm.a, you get that set, but if you leave
> it out, the ones in libc.a get used.
> 

Thanks.  I already know that but that's the (slow and ugly) method I use
to find why an archive member causing a link error is linked in.  What I need
is a clean and fast method, e.g. a gld option or, better, a direct information
in the error message.

Philippe


From ian@cygnus.com  Mon Dec 29 20:09:00 1997
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 29 Dec 1997 20:09:00 -0000
Subject: why is an archive member linked in ?
References: <199712300309.EAA31445@mail.macqel.be>
Message-ID: <199712300409.XAA25552@subrogation.cygnus.com>

   Date: Tue, 30 Dec 1997 04:09:04 +0100 (MET)
   From: "Philippe De Muyter" <phdm@macqel.be>

   I need to answer the following ld-related question : why is some specific
   archive-member linked in ?  Is there a gld option available 
   or some other more intricated way  to answer that question ?

Use the -M/-Map option, and look at the top of the mapfile.

Ian