More gas/bfd patches

More gas/bfd patches

[Bryan Ford]

OK, here are three more patches, based on the gas-950208 snapshot.
I've verified that they merge cleanly into gas-950219.

The first is just another minor bug fix to the 16-bit i386 support:

diff -ur gas-950208/include/opcode/i386.h gas-new/include/opcode/i386.h
--- gas-950208/include/opcode/i386.h	Mon Feb  6 12:00:43 1995
+++ gas-new/include/opcode/i386.h	Sun Feb 19 10:06:03 1995
@@ -101,6 +101,8 @@
 {"sahf", 0, 0x9e, _, NoModrm, { 0, 0, 0} },
 {"pushf", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
 {"popf", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
+{"pushfl", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
+{"popfl", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
 {"pushfw", 0, 0x9c, _, NoModrm|Data16, { 0, 0, 0} },
 {"popfw", 0, 0x9d, _, NoModrm|Data16, { 0, 0, 0} },
 {"stc", 0, 0xf9, _, NoModrm, { 0, 0, 0} },
@@ -280,8 +282,10 @@
 {"lret", 1, 0xca, _, NoModrm|Data32, { Imm16, 0, 0} },
 {"lretw", 0, 0xcb, _, NoModrm|Data16, { 0, 0, 0} },
 {"lretw", 1, 0xca, _, NoModrm|Data16, { Imm16, 0, 0} },
-{"enter", 2, 0xc8, _, NoModrm, { Imm16, Imm8, 0} },
-{"leave", 0, 0xc9, _, NoModrm, { 0, 0, 0} },
+{"enter", 2, 0xc8, _, NoModrm|Data32, { Imm16, Imm8, 0} },
+{"leave", 0, 0xc9, _, NoModrm|Data32, { 0, 0, 0} },
+{"enterw", 2, 0xc8, _, NoModrm|Data16, { Imm16, Imm8, 0} },
+{"leavew", 0, 0xc9, _, NoModrm|Data16, { 0, 0, 0} },
 
 /* conditional jumps */
 {"jo", 1, 0x70, _, Jump, { Disp, 0, 0} },


The second is a minor fix to bfd/libaout.h that I needed 
in order to get bfd to compile here:

diff -cr gas-950208/bfd/libaout.h gas-950208-new/bfd/libaout.h
*** gas-950208/bfd/libaout.h	Thu Feb  9 08:04:33 1995
--- gas-950208-new/bfd/libaout.h	Thu Feb  9 08:08:55 1995
***************
*** 442,448 ****
  NAME(aout,swap_std_reloc_in) PARAMS ((bfd *, struct reloc_std_external *,
  				      arelent *, asymbol **));
  
! CONST struct reloc_howto_struct *
  NAME(aout,reloc_type_lookup) PARAMS ((bfd *abfd,
  				      bfd_reloc_code_real_type code));
  
--- 442,448 ----
  NAME(aout,swap_std_reloc_in) PARAMS ((bfd *, struct reloc_std_external *,
  				      arelent *, asymbol **));
  
! reloc_howto_type *
  NAME(aout,reloc_type_lookup) PARAMS ((bfd *abfd,
  				      bfd_reloc_code_real_type code));
  

The third is a little more interesting - it adds read support
to the "binary" BFD backend.  Basically, if you specify "binary"
as the format of an input file to ld or objcopy or whatever,
the input file will be read into a data section as raw, uninterpreted bytes,
and some symbols will be produced, based on the filename of the input file,
marking the start and end of the data chunk.  Basically, it allows you
to link arbitrary files into a program without all the machine-dependent,
format-dependent "wrap-a-file-in-a-.o" kludgery that's usually needed.
(e.g. see the Linux boot image creation mechanism. :-) )

The binary BFD reader will only be enabled when it is specifically
requested by name; it will never "match" when an automatic BFD format
search is being done.

I didn't find any documentation on the binary BFD backend (or on any
other BFD backends for that matter); if there is some, point me to it
and I'll add appropriate documentation for the reader.

BTW, this code requires a horrible kludge to find the size of the
input file, because bfd_seek doesn't support SEEK_END, and by definition
there's no way to find the length of an uninterpreted binary input file
based only its contents.  (I just read through the file once and count
the number of bytes before EOF.)  I noticed that the srec reader also
needs to detect EOF.  Maybe it would be a good idea to enable SEEK_END
in bfd_seek(), and simply make it known that certain file formats
cannot be placed in archives.  Perhaps modify the ASSERT in bfd_seek()
to die only if someone tries to bfd_seek in an archive...?

				Bryan

diff -ur gas-950208/bfd/binary.c gas-new/bfd/binary.c
--- gas-950208/bfd/binary.c	Wed Oct 19 12:08:55 1994
+++ gas-new/bfd/binary.c	Sat Feb 18 13:48:50 1995
@@ -31,10 +31,16 @@
    the file.  objcopy cooperates by specially setting the start
    address to zero by default.  */
 
+#include <ctype.h>
+
 #include "bfd.h"
 #include "sysdep.h"
 #include "libbfd.h"
 
+/* Any bfd we create by reading a binary file has three symbols:
+   a start symbol, an end symbol, and an absolute length symbol.  */
+#define BIN_SYMS 2
+
 static boolean binary_mkobject PARAMS ((bfd *));
 static asymbol *binary_make_empty_symbol PARAMS ((bfd *));
 static boolean binary_set_section_contents
@@ -50,15 +56,29 @@
 }
 
 /* Most of the symbol routines can just return an error.  */
-#define binary_get_symtab_upper_bound _bfd_nosymbols_get_symtab_upper_bound
-#define binary_get_symtab _bfd_nosymbols_get_symtab
+#define	binary_close_and_cleanup _bfd_generic_close_and_cleanup
+#define binary_bfd_free_cached_info _bfd_generic_bfd_free_cached_info
+#define binary_new_section_hook _bfd_generic_new_section_hook
+
 #define binary_print_symbol _bfd_nosymbols_print_symbol
-#define binary_get_symbol_info _bfd_nosymbols_get_symbol_info
-#define binary_bfd_is_local_label _bfd_nosymbols_bfd_is_local_label
+#define binary_bfd_is_local_label bfd_generic_is_local_label
 #define binary_get_lineno _bfd_nosymbols_get_lineno
 #define binary_find_nearest_line _bfd_nosymbols_find_nearest_line
 #define binary_bfd_make_debug_symbol _bfd_nosymbols_bfd_make_debug_symbol
 
+#define binary_get_reloc_upper_bound \
+  ((long (*) PARAMS ((bfd *, asection *))) bfd_0l)
+#define binary_canonicalize_reloc \
+  ((long (*) PARAMS ((bfd *, asection *, arelent **, asymbol **))) bfd_0l)
+#define binary_bfd_reloc_type_lookup _bfd_norelocs_bfd_reloc_type_lookup
+
+#define binary_bfd_get_relocated_section_contents \
+  bfd_generic_get_relocated_section_contents
+#define binary_bfd_relax_section bfd_generic_relax_section
+#define binary_bfd_link_hash_table_create _bfd_generic_link_hash_table_create
+#define binary_bfd_link_add_symbols _bfd_generic_link_add_symbols
+#define binary_bfd_final_link _bfd_generic_final_link
+
 /* We do have to provide a routine to make an empty symbol.  */
 
 static asymbol *
@@ -108,6 +128,176 @@
   return _bfd_generic_set_section_contents (abfd, sec, data, offset, size);
 }
 
+/* Check whether an existing file is a binary file.
+   Pretty easy - _every_ file is as far as we're concerned. :-)
+   However, only "recognize" the file
+   if the input target was explicitly set to "binary",
+   not if we're doing an automatic target search.  */
+
+static const bfd_target *
+binary_object_p (abfd)
+     bfd *abfd;
+{
+  long bytes;
+
+  if (abfd->target_defaulted)
+    return NULL;
+
+  abfd->symcount = BIN_SYMS;
+
+  /* Find the file size.  XXX big kludge,
+     because bfd_seek doesn't like SEEK_END.  */
+  {
+    bfd_byte c;
+
+    if (bfd_seek (abfd, (file_ptr) 0, SEEK_SET) != 0)
+      return NULL;
+
+    bytes = 0;
+    while (bfd_read (&c, 1, 1, abfd) == 1)
+      bytes++;
+
+    if (bfd_get_error () != bfd_error_file_truncated)
+      return NULL;
+  }
+
+  /* One data section.  */
+  {
+    asection *sec;
+    char *secname;
+
+    secname = (char *) bfd_alloc (abfd, strlen (".data") + 1);
+    strcpy (secname, ".data");
+    sec = bfd_make_section (abfd, secname);
+    if (sec == NULL)
+      return NULL;
+    sec->flags = SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS;
+    sec->vma = 0;
+    sec->_raw_size = bytes;
+    sec->filepos = 0;
+
+    abfd->tdata.any = (PTR)sec;
+  }
+
+  return abfd->xvec;
+}
+
+/* Get the contents of "the" section.  */
+
+static boolean
+binary_get_section_contents (abfd, section, location, offset, count)
+     bfd *abfd;
+     asection *section;
+     PTR location;
+     file_ptr offset;
+     bfd_size_type count;
+{
+  if ((bfd_seek (abfd, offset, SEEK_SET) != 0)
+      || (bfd_read (location, 1, count, abfd) != count))
+    return false;
+  return true;
+}
+
+/* Return the amount of memory needed to read the symbol table.  */
+
+static long
+binary_get_symtab_upper_bound (abfd)
+     bfd *abfd;
+{
+  return (BIN_SYMS + 1) * sizeof (asymbol *);
+}
+
+void
+binary_get_symbol_info (ignore_abfd, symbol, ret)
+     bfd *ignore_abfd;
+     asymbol *symbol;
+     symbol_info *ret;
+{
+  bfd_symbol_info (symbol, ret);
+}
+
+/* Create a symbol name based on the bfd's filename.  */
+static char *mangle_name(abfd, suffix)
+     bfd *abfd;
+     char *suffix;
+{
+  int size = strlen(bfd_get_filename(abfd)) + strlen(suffix) + 10;
+  char *buf = (char*) bfd_alloc (abfd, size);
+  char *p;
+
+  if (buf == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  sprintf(buf, "_binary_%s_%s", bfd_get_filename(abfd), suffix);
+
+  /* Change any non-alphanumeric characters to underscores.  */
+  for (p = buf; *p; p++)
+    if (!isalnum(*p))
+      *p = '_';
+
+  return buf;
+}
+
+/* Return the symbol table.  */
+
+static long
+binary_get_symtab (abfd, alocation)
+     bfd *abfd;
+     asymbol **alocation;
+{
+  asection *sec = (asection*)abfd->tdata.any;
+  asymbol *syms;
+  unsigned int i;
+
+  syms = (asymbol *) bfd_alloc (abfd, BIN_SYMS * sizeof (asymbol));
+  if (syms == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  /* Start symbol.  */
+  syms[0].the_bfd = abfd;
+  syms[0].name = mangle_name(abfd, "start");
+  syms[0].value = 0;
+  syms[0].flags = BSF_GLOBAL;
+  syms[0].section = sec;
+  syms[0].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[1].the_bfd = abfd;
+  syms[1].name = mangle_name(abfd, "end");
+  syms[1].value = sec->_raw_size;
+  syms[1].flags = BSF_GLOBAL;
+  syms[1].section = sec;
+  syms[1].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[2].the_bfd = abfd;
+  syms[2].name = mangle_name(abfd, "size");
+  syms[2].value = sec->_raw_size;
+  syms[2].flags = BSF_GLOBAL;
+  syms[2].section = bfd_abs_section_ptr;
+  syms[2].udata.p = NULL;
+
+  for (i = 0; i < BIN_SYMS; i++)
+    *alocation++ = syms++;
+  *alocation = NULL;
+
+  return BIN_SYMS;
+}
+
+static int
+binary_sizeof_headers (abfd, exec)
+     bfd *abfd;
+     boolean exec;
+{
+  return 0;
+}
+
 const bfd_target binary_vec =
 {
   "binary",			/* name */
@@ -129,7 +319,7 @@
   bfd_getb16, bfd_getb_signed_16, bfd_putb16,	/* hdrs */
   {				/* bfd_check_format */
     _bfd_dummy_target,
-    _bfd_dummy_target,
+    binary_object_p,		/* bfd_check_format */
     _bfd_dummy_target,
     _bfd_dummy_target,
   },
@@ -146,14 +336,14 @@
     bfd_false,
   },
 
-  BFD_JUMP_TABLE_GENERIC (_bfd_generic),
+  BFD_JUMP_TABLE_GENERIC (binary),
   BFD_JUMP_TABLE_COPY (_bfd_generic),
   BFD_JUMP_TABLE_CORE (_bfd_nocore),
   BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
   BFD_JUMP_TABLE_SYMBOLS (binary),
-  BFD_JUMP_TABLE_RELOCS (_bfd_norelocs),
+  BFD_JUMP_TABLE_RELOCS (binary),
   BFD_JUMP_TABLE_WRITE (binary),
-  BFD_JUMP_TABLE_LINK (_bfd_nolink),
+  BFD_JUMP_TABLE_LINK (binary),
   BFD_JUMP_TABLE_DYNAMIC (_bfd_nodynamic),
 
   NULL

Re: More gas/bfd patches

[Ian Lance Taylor]

   Date: Mon, 20 Feb 95 09:05:36 MST
   From: Bryan Ford <baford@schirf.cs.utah.edu>

   The third is a little more interesting - it adds read support
   to the "binary" BFD backend.  Basically, if you specify "binary"
   as the format of an input file to ld or objcopy or whatever,
   the input file will be read into a data section as raw, uninterpreted bytes,
   and some symbols will be produced, based on the filename of the input file,
   marking the start and end of the data chunk.  Basically, it allows you
   to link arbitrary files into a program without all the machine-dependent,
   format-dependent "wrap-a-file-in-a-.o" kludgery that's usually needed.
   (e.g. see the Linux boot image creation mechanism. :-) )

Note that objcopy now supports the --add-section option.  It's not
quite the same thing, though, I suppose.

   BTW, this code requires a horrible kludge to find the size of the
   input file, because bfd_seek doesn't support SEEK_END, and by definition
   there's no way to find the length of an uninterpreted binary input file
   based only its contents.  (I just read through the file once and count
   the number of bytes before EOF.)

Why not just use stat?

Ian

Add -N support to ELF?

[H.J. Lu]

I have been thinking to add -N support to ELF. The current ELF code
will put all sections into one segment if it can. It somewhat works
like -N. If the text section ends on a page boundary and the data
section starts right after it, both sections will be put into one 
big segment. That means the binary may not be sharable. The current
solution is skip a page if that happens. I was wondering if we
could change it such that:

1. When -N is not used, if the sh_flags of the current section
   is not compatible with the p_flags of the current segment, start
   a new segment.

2. When -N is used, behave just like the old way.

I can make the changes. But I don't think may changes will be
acceptable to everyone :-(. Will a new field in bfd_link_info help?

Thanks.

H.J.

Re: Add -N support to ELF?

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 13:30:57 EST

   1. When -N is not used, if the sh_flags of the current section
      is not compatible with the p_flags of the current segment, start
      a new segment.

   2. When -N is used, behave just like the old way.

This seems reasonable in principle.  The trick is defining
``compatible'' is a useful fashion.  I have not been able to think of
a good definition, but I haven't thought about it all that much,
either.

   I can make the changes. But I don't think may changes will be
   acceptable to everyone :-(. Will a new field in bfd_link_info help?

A new field is not necessary.  Check the flags field of the output
field, and switch on the D_PAGED flag.  D_PAGED is set by default, and
turned off when -N (or -n) is used.  For example, the a.out backend
uses D_PAGED to determine whether the output file should be zmagic or
omagic.

Ian

Re: Add -N support to ELF?

[H.J. Lu]

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 13:30:57 EST
> 
>    1. When -N is not used, if the sh_flags of the current section
>       is not compatible with the p_flags of the current segment, start
>       a new segment.
> 
>    2. When -N is used, behave just like the old way.
> 
> This seems reasonable in principle.  The trick is defining
> ``compatible'' is a useful fashion.  I have not been able to think of
> a good definition, but I haven't thought about it all that much,
> either.

By "compatible", I mean 

((hdr->sh_flags & SHF_WRITE) && (phdr->p_flags & PF_W))

or

((hdr->sh_flags & SHF_WRITE) == 0 && (phdr->p_flags & PF_W) == 0)

As a matter of fact, the code is already there in elfcode.h in
my source tree. But it is commented out with

/* FIXME: ctors/dtors contain the code, but are r/w. */

We have moved ctors/dtors into the data section. That won't
be the problem any more. But this may break those embedded systems.


H.J.

Re: Add -N support to ELF?

[H.J. Lu]

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 13:30:57 EST
> 
>    1. When -N is not used, if the sh_flags of the current section
>       is not compatible with the p_flags of the current segment, start
>       a new segment.
> 
>    2. When -N is used, behave just like the old way.
> 
> This seems reasonable in principle.  The trick is defining
> ``compatible'' is a useful fashion.  I have not been able to think of
> a good definition, but I haven't thought about it all that much,
> either.
> 
>    I can make the changes. But I don't think may changes will be
>    acceptable to everyone :-(. Will a new field in bfd_link_info help?
> 
> A new field is not necessary.  Check the flags field of the output
> field, and switch on the D_PAGED flag.  D_PAGED is set by default, and
> turned off when -N (or -n) is used.  For example, the a.out backend
> uses D_PAGED to determine whether the output file should be zmagic or
> omagic.
> 
> Ian
> 

This patch is derived from some patch I got, Eric? It should work
fine. Ian, is that ok to uncomment my patch to elf.sc with this one
applied? I guess the docs should be updated to reflect the usage
of -N in ELF.

Thanks.



-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
*** elfcode.h	Sat Feb 18 10:25:01 1995
--- elfcode.h.new	Mon Feb 20 16:13:22 1995
***************
*** 1968,1974 ****
--- 1968,1986 ----
        if (phdr->p_type != PT_NULL
  	  && (hdr->sh_offset - (phdr->p_offset + phdr->p_memsz)
  	      == hdr->sh_addr - (phdr->p_vaddr + phdr->p_memsz))
+ #if 1
+ 	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS)
+ 	  /* We check to see if the binary is for demand page. We
+ 	     want to make sure the curent section is compatible with
+ 	     the current segment. Otherwise, start a new segment. We
+ 	     have to be very careful about elf.sc. Don't put any
+ 	     writable sections into the text segment. */
+ 	  && (((abfd->flags & D_PAGED) == 0)
+ 	      || (((hdr->sh_flags & SHF_WRITE) == 0 && (phdr->p_flags & PF_W) == 0)
+ 	      || ((hdr->sh_flags & SHF_WRITE) != 0 && (phdr->p_flags & PF_W) != 0))))
+ #else
  	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS))
+ #endif
  	{
  	  bfd_size_type adjust;
  

Re: Add -N support to ELF?

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 16:18:38 EST

   This patch is derived from some patch I got, Eric? It should work
   fine. Ian, is that ok to uncomment my patch to elf.sc with this one
   applied? I guess the docs should be updated to reflect the usage
   of -N in ELF.

The basic problem with this approach is that I believe it will cause
the linker to unexpectedly abort if, say, one of the input files has a
writable .text section.  Try it.

The linker already aborts unexpectedly far too often, and I would
prefer not to introduce another possibility.  If you can write the
patch in such a fashion that it can not cause a linker abort--perhaps
by making it retry the division of sections into segments if the first
attempt uses too many segments--I would be more willing to put this
in.  The beneficial effects of this patch are vanishingly small--it
saves one page of virtual memory address space (not virtual memory
itself, but just the address space) for a very small number of
programs--so IMHO it should only be put in if it is completely safe.

Ian

Re: Add -N support to ELF?

[H.J. Lu]

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 16:18:38 EST
> 
>    This patch is derived from some patch I got, Eric? It should work
>    fine. Ian, is that ok to uncomment my patch to elf.sc with this one
>    applied? I guess the docs should be updated to reflect the usage
>    of -N in ELF.
> 
> The basic problem with this approach is that I believe it will cause
> the linker to unexpectedly abort if, say, one of the input files has a
> writable .text section.  Try it.

I know. That is why I put those comments there and why Eric commented
it out at the first place. At that time, ctors/dtors were in the
.text segment.

> 
> The linker already aborts unexpectedly far too often, and I would
> prefer not to introduce another possibility.  If you can write the
> patch in such a fashion that it can not cause a linker abort--perhaps
> by making it retry the division of sections into segments if the first


I think it is wrong to put the writable section into the .text section.
It will break any schemes which uses the .text section like

const char * const foo = "You should die if you modify it.";

There must be a bug in somewhere else if ld dies. It is not my
patch's fault.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: Add -N support to ELF?

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 17:42:10 EST

   I think it is wrong to put the writable section into the .text section.
   It will break any schemes which uses the .text section like

   const char * const foo = "You should die if you modify it.";

From the linker's point of view, there is nothing wrong with having a
writable .text section.  The current linker will handle it correctly,
in the sense that it will produce a program segment which is marked
writable.

   There must be a bug in somewhere else if ld dies. It is not my
   patch's fault.

The bug is that given the standard ELF linker script in elf.sc, the
linker has to know the number of program segments it is going to
generate before it assigns addresses to any of the sections.  This is
because of the use of SIZEOF_HEADERS in elf.sc, which is used as is
normal for an ELF target.  Unfortunately, the GNU linker will ask the
BFD backend for the size of the header information before it has fully
sorted out the section layout of the input files.  It has no mechanism
for adjusting the header size based on the section layout.  Therefore,
the BFD backend will guess that only two segments are required.  If
more than two segments are required, the linker must abort.

You are absolutely correct in saying that this bug is not related to
your patch.

However, look at it from my perspective.  Right now, the linker will
always work correctly given the script in elf.sc, and (thanks to some
patches from Doug Evans) it will always work given a script which does
not use SIZEOF_HEADERS.  It will currently fail when given a script
which uses SIZEOF_HEADERS which does not arrange the sections
carefully.  It will also sometimes allocate an unnecessary page of
virtual address space.

Your patch fixes the last problem.  However, if your patch is applied,
it will no longer be the case that the linker will always work
correctly given the script in elf.sc.

To my mind, that is too heavy a price to pay.  The bug you are fixing
is a rather theoretical one--I may misunderstand something, but I
think I would find it difficult to construct a program which failed to
run without your patch.  If your patch were harmless, I would put it
in.  However, I believe that it is not harmless.

I believe that the correct thing to do is to permit the linker to
adjust SIZEOF_HEADERS based on the section layout.  However, that may
be a complicated task, I have very little time, and I am not aware of
any person who has actually encountered the problem.  If I receive
patches to fix that problem, I will put your patch in at that time.

Ian