[Linux-ia64] 001117 toolchain release

[Linux-ia64] 001117 toolchain release

[Jim Wilson]

I have put a new toolchain on ftp.cygnus.com in pub/ia64-linux/snap-001117.

This fixes all significant known toolchain problems.  I don't expect to be
adding more patches to the toolchain unless another serious toolchain bug is
found.

There is one more significant ABI change since the last release.  There was
a corresponding glibc change, so this requires an up-to-date glibc (Nov 16 or
later).  If you already have glibc 2.2, you need to recompile from scratch.
If you are trying to use this toolchain with glibc 2.1.3, then you need a
new copy of the README.glibc213 file, since this file now needs to revert 3 ABI
changes instead of 2.  Since there are no public OS distributions using glibc
2.2 yet, the glibc and toolchain maintainers decided it was better to fix ABI
bugs now than later.

I expect that the next toolchain release will be something based off of the
FSF gcc 3.0 tree sometime early next year.  This depends on when gcc 3.0 will
be available, and that is anybody's guess, but the general idea here is to get
all of us migrated to an official FSF release instead of the development
releases that we have been using.

Jim

Re: [Linux-ia64] 001117 toolchain release

[Keith Owens]

On Fri, 17 Nov 2000 21:34:58 -0800, 
Jim Wilson <wilson@cygnus.com> wrote:
>I have put a new toolchain on ftp.cygnus.com in pub/ia64-linux/snap-001117.
>
>This fixes all significant known toolchain problems.  I don't expect to be
>adding more patches to the toolchain unless another serious toolchain bug is
>found.

The unwind sections have alignment 2**0.  The only reason we get away
with it is that the preceding sections are aligned and are a multiple
of words.  If you add a section between __ksymtab and unwind that is
not a multiple of words then the results are "interesting".

  0 .text         0039a990  e000000000500000  0000000000500000  00010000  2**15
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 __ex_table    000019a0  e00000000089a990  000000000089a990  003aa990  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 __ksymtab     00004100  e00000000089c330  000000000089c330  003ac330  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .IA_64.unwind 000240a8  e0000000008a0430  00000000008a0430  003b0430  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .IA_64.unwind_info 0002ca00  e0000000008c44e0  00000000008c44e0  003d44e0  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

Temporary fix, against 2.4.0-test11.

Index: 0-test11.7/arch/ia64/vmlinux.lds.S
--- 0-test11.7/arch/ia64/vmlinux.lds.S Mon, 20 Nov 2000 18:27:00 +1100 kaos (linux-2.4/b/c/8_vmlinux.ld 1.3.1.1.3.1 644)
+++ 0-test11.7(w)/arch/ia64/vmlinux.lds.S Tue, 21 Nov 2000 14:36:37 +1100 kaos (linux-2.4/b/c/8_vmlinux.ld 1.3.1.1.3.1 644)
@@ -65,9 +65,11 @@ SECTIONS
 
   /* Unwind table */
+  . = ALIGN(16);
   ia64_unw_start = .;
   .IA_64.unwind : AT(ADDR(.IA_64.unwind) - PAGE_OFFSET)
 	{ *(.IA_64.unwind) }
   ia64_unw_end = .;
+  . = ALIGN(16);
   .IA_64.unwind_info : AT(ADDR(.IA_64.unwind_info) - PAGE_OFFSET)
 	{ *(.IA_64.unwind_info) }

Re: [Linux-ia64] 001117 toolchain release

[Jim Wilson]

Why 16 bytes?  The sections only have 8 byte data.  (Technically, the unwind
section has 4 byte data for the 32-bit ABI, but I'm ignoring that for now.)

I added this patch to the FSF binutils sources to fix the problem.  I am not
planning to add a patch for the 001117 release, since this doesn't seem to
be a serious enough problem.

2000-11-21  Jim Wilson  <wilson@redhat.com>

	* config/tc-ia64.c (generate_unwind_image): Call record_alignment
	for unwind info section.
	(dot_endp): Likewise for unwind section.

Index: tc-ia64.c
=================================RCS file: /cvs/src/src/gas/config/tc-ia64.c,v
retrieving revision 1.33
diff -p -r1.33 tc-ia64.c
*** tc-ia64.c	2000/11/22 01:12:05	1.33
--- tc-ia64.c	2000/11/22 02:01:42
*************** generate_unwind_image ()
*** 3057,3062 ****
--- 3057,3065 ----
        expressionS exp;
        set_section ((char *) special_section_name[SPECIAL_SECTION_UNWIND_INFO]);
  
+       /* Make sure the section has 8 byte alignment.  */
+       record_alignment (now_seg, 3);
+ 
        /* Set expression which points to start of unwind descriptor area.  */
        unwind.info = expr_build_dot ();
  
*************** dot_endp (dummy)
*** 3684,3689 ****
--- 3687,3696 ----
    unwind.proc_end = expr_build_dot ();
  
    set_section ((char *) special_section_name[SPECIAL_SECTION_UNWIND]);
+ 
+   /* Make sure the section has 8 byte alignment.  */
+   record_alignment (now_seg, 3);
+ 
    ptr = frag_more (24);
    where = frag_now_fix () - 24;
    bytes_per_address = bfd_arch_bits_per_address (stdoutput) / 8;

Re: [Linux-ia64] 001117 toolchain release

[Keith Owens]

On Tue, 21 Nov 2000 18:18:50 -0800, 
Jim Wilson <wilson@cygnus.com> wrote:
>Why 16 bytes?  The sections only have 8 byte data.  (Technically, the unwind
>section has 4 byte data for the 32-bit ABI, but I'm ignoring that for now.)

I did not have the software conventions guide handy at the time.  16
was a "better safe than sorry" value.