This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Committed: Fix mmix-knuth-mmixware ld test results.


The test results for mmix-knuth-mmixware had FAILs, now there are none for
any of gas, binutils and ld.  I could surely just have xfailed or skipped
the failing tests, but this is better.

The FAILs were due to symbols showing up as absolute symbols when expected
to be in .data or .text, or contents not accurately mapped to the linked
section, e.g. .data being dumped as .text.  This was due to absence of
section descriptions for .text and .data for the mmo format.  The format
doesn't have sections; just vma and contents, though the contents normally
used as .text and .data have expected locations, in turn used to deduce
those sections for BFD.  On top of that, any contents defaults to 0 and
Knuth's assembler mmixal makes use of that.  So does BFD in order to
generate the same output; leading and trailing zeros are stripped.  This
makes deduction of the actual section vma or contents ambiguous.  The
minimal interpretation is used when reading in an mmo file.

There is a kind-of-extension-data specifier abused by bfd/mmo.c to
shoehorn in section descriptions using a special format (see BFD docs).
In the name of simplicity and interoperability, until now no such section
descriptions have been output for .text and .data; only for other linked
sections.  Even now, to meet supposed user expectation no section
description is output if the trivial interpretation would be correct.

All new code paths are exercised through the existing tests (mostly the
failing ones) outside ld-mmix.  One ld-mmix test had to be rewritten; the
old test was adjusted and kept under a new name.  I like having tests.
(Yeah, I know this is still PARAMS and stuff.  Film at 11.)

bfd:
	* mmo.c (mmo_write_section_description): New function broken out
	of mmo_internal_write_section.
	(mmo_internal_write_section): For each of .text and .data, call
	mmo_write_section_description before outputting contents if it has
	nontrivially deducible vma or contents.
	(mmo_has_leading_or_trailing_zero_tetra_p): New function.
	(mmo_canonicalize_symtab): Adjust absolute symbols to .data
	symbols if found within the .data address range.

ld/testsuite:
	* ld-mmix/sec-8m.d: Adjust test for dump using correct section
	length.
	* ld-mmix/sec-9.d: Renamed test, formerly known as sec-5.d.
	* ld-mmix/sec-5.d, ld-mmix/b-offloc.s: Rewritten test.

Index: sec-5.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-mmix/sec-5.d,v
retrieving revision 1.3
diff -p -c -u -p -r1.3 sec-5.d
cvs diff: conflicting specifications of output style
--- sec-5.d	12 May 2003 05:45:38 -0000	1.3
+++ sec-5.d	24 Oct 2004 20:28:25 -0000
@@ -1,21 +1,28 @@
-#source: start.s
-#ld: -m mmo -T $srcdir/$subdir/mmosec2.ld
+#source: b-twoinsn.s
+#source: b-offloc.s
+#source: b-post1.s
+#source: b-goodmain.s
+#ld: --oformat binary
 #objdump: -sh

 # Check that sections are automatically created to cope with contents at
-# unexpected addresses.  We do this by linking .text at an unexpected
-# address.  As .text (like .data) does not get a section descriptor, the
-# output gets a LOP_LOC at an unexpected address, and a unique section is
-# created.  This test will have to be changed if .text gets a section
-# descriptor if linked to an unexpected address.
+# unexpected addresses when an mmo is read in.  We used to do this by
+# e.g. linking .text at an unexpected address, like in sec-9.d.  That no
+# longer works, because .text and .data now gets section descriptors at
+# mmo output when the address and contents doesn't trivially reflect the
+# section contents at link time.  To test, we instead read in an mmo
+# formed from a link to binary format, like the b-*.d tests for mmo
+# execution paths.

 .*:     file format mmo

 Sections:
 Idx Name          Size      VMA               LMA               File off  Algn
-  0 \.text         0+  0+  0+  0+  2\*\*2
-
-  1 \.MMIX\.sec\.0   0+4  1000000000000000  1000000000000000  0+  2\*\*2
+  0 \.text         0+8  0+  0+  0+  2\*\*2
+                  CONTENTS, ALLOC, LOAD, CODE
+  1 \.MMIX\.sec\.0   0+10  789abcdef0123458  789abcdef0123458  0+  2\*\*2
                   CONTENTS, ALLOC, LOAD
+Contents of section \.text:
+ 0+ e3fd0001 e3fd0004                  .*
 Contents of section \.MMIX\.sec\.0:
- 1000000000000000 e3fd0001                             .*
+ 789abcdef0123458 b045197d 2c1b03b2 e4dbf877 0fc766fb  .*
--- /dev/null	Tue Jan  1 05:00:00 1980
+++ b-offloc.s	Sun Oct 24 22:29:28 2004
@@ -0,0 +1,9 @@
+% The .text contents is supposed to be linked --oformat binary with
+% b-post1.s and b-goodmain.s.  The code below will provide a LOP_LOC
+% with a 64-bit address (0x789abcdef0123456) then 16 bytes of % random data.
+
+ .text
+ .byte 0x98,1,0,2
+ .8byte 0x789abcdef0123458
+ .byte 0xb0,0x45,0x19,0x7d,0x2c,0x1b,0x3,0xb2
+ .byte 0xe4,0xdb,0xf8,0x77,0xf,0xc7,0x66,0xfb
Index: sec-8m.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-mmix/sec-8m.d,v
retrieving revision 1.2
diff -p -c -r1.2 sec-8m.d
*** sec-8m.d	12 May 2003 05:45:38 -0000	1.2
--- sec-8m.d	24 Oct 2004 21:24:12 -0000
***************
*** 13,19 ****
  # with a leading multiple-of-four number of zero bytes, those zero bytes
  # would be omitted, and the "saved" bytes would be concatenated with the
  # following (not-all-zeros) bytes.  Hence a shift of the last bytes of the
! # first chunk.  Note that the section will be padded in the output.

  .*:     file format mmo

--- 13,19 ----
  # with a leading multiple-of-four number of zero bytes, those zero bytes
  # would be omitted, and the "saved" bytes would be concatenated with the
  # following (not-all-zeros) bytes.  Hence a shift of the last bytes of the
! # first chunk.

  .*:     file format mmo

*************** Contents of section \.text:
*** 27,30 ****
   10010 33000000 00000000 00000000 00000000  .*
   10020 00300000 00000000 00000000 00000000  .*
  #...
!  18020 31000000  .*
--- 27,30 ----
   10010 33000000 00000000 00000000 00000000  .*
   10020 00300000 00000000 00000000 00000000  .*
  #...
!  18020 31        .*
--- /dev/null	Tue Jan  1 05:00:00 1980
+++ sec-9.d	Sun Oct 24 21:31:22 2004
@@ -0,0 +1,19 @@
+#source: start.s
+#ld: -m mmo -T $srcdir/$subdir/mmosec2.ld
+#objdump: -sh
+
+# This is based on sec-5.d which used to link .text at an unexpected
+# address to check that a special section was created in objdump when
+# reading in contents at an unusual location without a proper section
+# descriptor.  As .text (like .data) now gets a section descriptor when
+# linked to an unexpected location, the old test is transformed into a
+# specific check that the section description for .text works.
+
+.*:     file format mmo
+
+Sections:
+Idx Name          Size      VMA               LMA               File off  Algn
+  0 \.text         0+4  1000000000000000  1000000000000000  0+  2\*\*2
+                  CONTENTS, ALLOC, LOAD, READONLY, CODE
+Contents of section \.text:
+ 1000000000000000 e3fd0001                             .*

Index: mmo.c
===================================================================
RCS file: /cvs/src/src/bfd/mmo.c,v
retrieving revision 1.22
diff -p -c -r1.22 mmo.c
*** mmo.c	24 Oct 2004 14:09:16 -0000	1.22
--- mmo.c	24 Oct 2004 20:38:38 -0000
*************** static bfd_boolean mmo_write_object_cont
*** 464,469 ****
--- 464,473 ----
    PARAMS ((bfd *));
  static long mmo_canonicalize_reloc
    PARAMS ((bfd *, sec_ptr, arelent **, asymbol **));
+ static bfd_boolean mmo_write_section_description
+   PARAMS ((bfd *, asection *));
+ static bfd_boolean mmo_has_leading_or_trailing_zero_tetra_p
+   PARAMS ((bfd *, asection *));

  /* Global "const" variables initialized once.  Must not depend on
     particular input or caller; put such things into the bfd or elsewhere.
*************** mmo_canonicalize_symtab (abfd, alocation
*** 2264,2269 ****
--- 2268,2274 ----
  	    {
  	      asection *textsec
  		= bfd_get_section_by_name (abfd, MMO_TEXT_SECTION_NAME);
+ 	      asection *datasec;

  	      if (textsec != NULL
  		  && c->value >= textsec->vma
*************** mmo_canonicalize_symtab (abfd, alocation
*** 2272,2277 ****
--- 2277,2299 ----
  		  c->section = textsec;
  		  c->value -= c->section->vma;
  		}
+ 	      /* In mmo, symbol types depend on the VMA.  Therefore, if
+ 		 the data section isn't within the usual bounds, its
+ 		 symbols are marked as absolute.  Correct that.  This
+ 		 means we can't have absolute symbols with values matching
+ 		 data section addresses, but we also can't have with
+ 		 absolute symbols with values matching text section
+ 		 addresses.  For such needs, use the ELF format.  */
+ 	      else if ((datasec
+ 			= bfd_get_section_by_name (abfd,
+ 						   MMO_DATA_SECTION_NAME))
+ 		       != NULL
+ 		       && c->value >= datasec->vma
+ 		       && c->value <= datasec->vma + datasec->size)
+ 		{
+ 		  c->section = datasec;
+ 		  c->value -= c->section->vma;
+ 		}
  	      else
  		c->section = bfd_abs_section_ptr;
  	    }
*************** bfd_sec_flags_from_mmo_flags (flags)
*** 2441,2446 ****
--- 2463,2489 ----
    return oflags;
  }

+ /* Return TRUE iff the leading or trailing tetrabyte in SEC is defined and
+    is 0.  */
+
+ static bfd_boolean
+ mmo_has_leading_or_trailing_zero_tetra_p (abfd, sec)
+      bfd *abfd;
+      asection *sec;
+ {
+   bfd_vma secaddr = bfd_get_section_vma (abfd, sec);
+
+   if (sec->size < 4)
+     return FALSE;
+
+   if (bfd_get_32 (abfd, mmo_get_loc (sec, secaddr, 4)) == 0
+       && bfd_get_32 (abfd,
+ 		     mmo_get_loc (sec, secaddr + sec->size - 4, 4)) == 0)
+     return TRUE;
+
+   return FALSE;
+ }
+
  /* Write a section.  */

  static bfd_boolean
*************** mmo_internal_write_section (abfd, sec)
*** 2461,2470 ****
     above.  */

    if (strcmp (sec->name, MMO_TEXT_SECTION_NAME) == 0)
!     /* FIXME: Output source file name and line number.  */
!     return mmo_write_loc_chunk_list (abfd, mmo_section_data (sec)->head);
    else if (strcmp (sec->name, MMO_DATA_SECTION_NAME) == 0)
!     return mmo_write_loc_chunk_list (abfd, mmo_section_data (sec)->head);
    else if (strcmp (sec->name, MMIX_REG_CONTENTS_SECTION_NAME) == 0)
      /* Not handled here.  */
      {
--- 2504,2547 ----
     above.  */

    if (strcmp (sec->name, MMO_TEXT_SECTION_NAME) == 0)
!     {
!       bfd_vma secaddr = bfd_get_section_vma (abfd, sec);
!
!       /* Because leading and trailing zeros are omitted in output, we need to
! 	 specify the section boundaries so they're correct when the file
! 	 is read in again.  That's also the case if this section is
! 	 specified as not within its usual boundaries or alignments.  */
!       if (sec->size != 0
! 	  && (secaddr + sec->size >= (bfd_vma) 1 << 56
! 	      || (secaddr & 3) != 0
! 	      || (sec->size & 3) != 0
! 	      || mmo_has_leading_or_trailing_zero_tetra_p (abfd, sec)))
! 	{
! 	  if (!mmo_write_section_description (abfd, sec))
! 	    return FALSE;
! 	}
!
!       /* FIXME: Output source file name and line number.  */
!       return mmo_write_loc_chunk_list (abfd, mmo_section_data (sec)->head);
!     }
    else if (strcmp (sec->name, MMO_DATA_SECTION_NAME) == 0)
!     {
!       bfd_vma secaddr = bfd_get_section_vma (abfd, sec);
!
!       /* Same goes as for MMO_TEXT_SECTION_NAME above.  */
!       if (sec->size != 0
! 	  && (secaddr < (bfd_vma) 0x20 << 56
! 	      || secaddr + sec->size >= (bfd_vma) 0x21 << 56
! 	      || (secaddr & 3) != 0
! 	      || (sec->size & 3) != 0
! 	      || mmo_has_leading_or_trailing_zero_tetra_p (abfd, sec)))
! 	{
! 	  if (!mmo_write_section_description (abfd, sec))
! 	    return FALSE;
! 	}
!
!       return mmo_write_loc_chunk_list (abfd, mmo_section_data (sec)->head);
!     }
    else if (strcmp (sec->name, MMIX_REG_CONTENTS_SECTION_NAME) == 0)
      /* Not handled here.  */
      {
*************** mmo_internal_write_section (abfd, sec)
*** 2486,2492 ****
    else if ((bfd_get_section_flags (abfd, sec) & SEC_HAS_CONTENTS) != 0
  	   && sec->size != 0)
      {
!       /* Keep the document-comment formatted the way it is.  */
  /*
  INODE
  mmo section mapping, , Symbol-table, mmo
--- 2563,2593 ----
    else if ((bfd_get_section_flags (abfd, sec) & SEC_HAS_CONTENTS) != 0
  	   && sec->size != 0)
      {
!       if (!mmo_write_section_description (abfd, sec))
! 	return FALSE;
!
!       /* Writing a LOP_LOC ends the LOP_SPEC data, and makes data actually
! 	 loaded.  */
!       if (bfd_get_section_flags (abfd, sec) & SEC_LOAD)
! 	return (! abfd->tdata.mmo_data->have_error
! 		&& mmo_write_loc_chunk_list (abfd,
! 					 mmo_section_data (sec)->head));
!       return (! abfd->tdata.mmo_data->have_error
! 	      && mmo_write_chunk_list (abfd, mmo_section_data (sec)->head));
!     }
!
!   /* Some section without contents.  */
!   return TRUE;
! }
!
! /* Write the description of a section, extended-mmo-style.  */
!
! static bfd_boolean
! mmo_write_section_description (abfd, sec)
!      bfd *abfd;
!      asection *sec;
! {
!   /* Keep the following document-comment formatted the way it is.  */
  /*
  INODE
  mmo section mapping, , Symbol-table, mmo
*************** EXAMPLE
*** 2579,2607 ****
  	special data.  The address is usually unimportant but might
  	provide information for e.g.@: the DWARF 2 debugging format.  */

!       mmo_write_tetra_raw (abfd, LOP_SPEC_SECTION);
!       mmo_write_tetra (abfd, (strlen (sec->name) + 3) / 4);
!       mmo_write_chunk (abfd, sec->name, strlen (sec->name));
!       mmo_flush_chunk (abfd);
!       /* FIXME: We can get debug sections (.debug_line & Co.) with a
! 	 section flag still having SEC_RELOC set.  Investigate.  This
! 	 might be true for all alien sections; perhaps mmo.em should clear
! 	 that flag.  Might be related to weak references.  */
!       mmo_write_tetra (abfd,
! 		       mmo_sec_flags_from_bfd_flags
! 		       (bfd_get_section_flags (abfd, sec)));
!       mmo_write_octa (abfd, sec->size);
!       mmo_write_octa (abfd, bfd_get_section_vma (abfd, sec));
!
!       /* Writing a LOP_LOC ends the LOP_SPEC data, and makes data actually
! 	 loaded.  */
!       if (bfd_get_section_flags (abfd, sec) & SEC_LOAD)
! 	return (! abfd->tdata.mmo_data->have_error
! 		&& mmo_write_loc_chunk_list (abfd,
! 					     mmo_section_data (sec)->head));
!       return (! abfd->tdata.mmo_data->have_error
! 	      && mmo_write_chunk_list (abfd, mmo_section_data (sec)->head));
!     }
    return TRUE;
  }

--- 2680,2698 ----
  	special data.  The address is usually unimportant but might
  	provide information for e.g.@: the DWARF 2 debugging format.  */

!   mmo_write_tetra_raw (abfd, LOP_SPEC_SECTION);
!   mmo_write_tetra (abfd, (strlen (sec->name) + 3) / 4);
!   mmo_write_chunk (abfd, sec->name, strlen (sec->name));
!   mmo_flush_chunk (abfd);
!   /* FIXME: We can get debug sections (.debug_line & Co.) with a section
!      flag still having SEC_RELOC set.  Investigate.  This might be true
!      for all alien sections; perhaps mmo.em should clear that flag.  Might
!      be related to weak references.  */
!   mmo_write_tetra (abfd,
! 		   mmo_sec_flags_from_bfd_flags
! 		   (bfd_get_section_flags (abfd, sec)));
!   mmo_write_octa (abfd, sec->size);
!   mmo_write_octa (abfd, bfd_get_section_vma (abfd, sec));
    return TRUE;
  }

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]