architecture status, please

architecture status, please

[Ulrich Drepper]

I think things have stablelized now and we can think about 2.3.2.  Do
all architectures which worked in 2.3.1 work now?  Are any other
architectures which didn't work in 2.3.1 close to working with the
current tree?

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: architecture status, please

[Franz Sirl]

On Wednesday 19 February 2003 23:41, Ulrich Drepper wrote:
> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

I have one small patch queued for tomorrow and need to check the Dist files. 
Besides that PPC32 is fine.

Franz.

Re: architecture status, please

[kaz Kojima]

Ulrich Drepper <drepper@redhat.com> wrote:
> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

I've heard from SH kernel people that the kernel fixes the syscall
ABI for pread/pwrite* since the old one didn't work properly on SH-4
anyway, and a small fix is required in libc.
I'll send a patch for it till tomorrow. There are no other known
problems on SH.

Regards,
	kaz

[PATCH] SH: fix pread/pwrite (Was: architecture status, please)

[kaz Kojima]

Hi,

This is a patch for syscall ABI fixing of pread/pread64/pwrite/pwrite64
on SH linux target. Kernel folks took the MIPS's way.

Regards,
	kaz
--
2003-02-20  Kaz Kojima  <kkojima@rr.iij4u.or.jp>

	* sysdeps/unix/sysv/linux/sh/pread.c: New file.
	* sysdeps/unix/sysv/linux/sh/pread64.c: Likewise.
	* sysdeps/unix/sysv/linux/sh/pwrite.c: Likewise.
	* sysdeps/unix/sysv/linux/sh/pwrite64.c: Likewise.

diff -u3prN ORIG/libc/sysdeps/unix/sysv/linux/sh/pread.c LOCAL/libc/sysdeps/unix/sysv/linux/sh/pread.c
--- ORIG/libc/sysdeps/unix/sysv/linux/sh/pread.c	Thu Jan  1 09:00:00 1970
+++ LOCAL/libc/sysdeps/unix/sysv/linux/sh/pread.c	Thu Feb 20 13:19:20 2003
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pread.c>
diff -u3prN ORIG/libc/sysdeps/unix/sysv/linux/sh/pread64.c LOCAL/libc/sysdeps/unix/sysv/linux/sh/pread64.c
--- ORIG/libc/sysdeps/unix/sysv/linux/sh/pread64.c	Thu Jan  1 09:00:00 1970
+++ LOCAL/libc/sysdeps/unix/sysv/linux/sh/pread64.c	Thu Feb 20 13:19:20 2003
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pread64.c>
diff -u3prN ORIG/libc/sysdeps/unix/sysv/linux/sh/pwrite.c LOCAL/libc/sysdeps/unix/sysv/linux/sh/pwrite.c
--- ORIG/libc/sysdeps/unix/sysv/linux/sh/pwrite.c	Thu Jan  1 09:00:00 1970
+++ LOCAL/libc/sysdeps/unix/sysv/linux/sh/pwrite.c	Thu Feb 20 13:19:20 2003
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pwrite.c>
diff -u3prN ORIG/libc/sysdeps/unix/sysv/linux/sh/pwrite64.c LOCAL/libc/sysdeps/unix/sysv/linux/sh/pwrite64.c
--- ORIG/libc/sysdeps/unix/sysv/linux/sh/pwrite64.c	Thu Jan  1 09:00:00 1970
+++ LOCAL/libc/sysdeps/unix/sysv/linux/sh/pwrite64.c	Thu Feb 20 13:19:20 2003
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pwrite64.c>

Re: [PATCH] SH: fix pread/pwrite (Was: architecture status, please)

[Ulrich Drepper]

kaz Kojima wrote:

> This is a patch for syscall ABI fixing of pread/pread64/pwrite/pwrite64
> on SH linux target. Kernel folks took the MIPS's way.

Thanks, I've added the patch.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: architecture status, please

[Andreas Jaeger]

Ulrich Drepper <drepper@redhat.com> writes:

> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

x86-64 works and passes the complete testsuite with the exception of
the linuxthreads/ex18 problem that I mentioned on libc-alpha.

But this didn't work in 2.3.1 either, so we're as good as before - and
in most areas we're better ;-).

So, feel free to go ahead.

A prerelease might be a good idea,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: architecture status, please

[Andreas Jaeger]

With a fixed kernel for x86-64, I just tested current CVS successfully
with:
- with-tls --without-thread
- normal (--without-tls --without-thread)

The whole testsuite passed.

So, the x86-64 architecture support looks fine with current CVS glibc
and current CVS kernel

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: architecture status, please

[Jakub Jelinek]

On Tue, Feb 25, 2003 at 03:15:00PM +0100, Andreas Jaeger wrote:
> 
> With a fixed kernel for x86-64, I just tested current CVS successfully
> with:
> - with-tls --without-thread
> - normal (--without-tls --without-thread)

and
--with-tls --with-__thread
is what I've tested yesterday (in addition to the usual
--with-tls --without-__thread).

> The whole testsuite passed.

Ditto.

	Jakub

Re: architecture status, please

[Richard Henderson]

On Wed, Feb 19, 2003 at 02:41:07PM -0800, Ulrich Drepper wrote:
> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?

Alpha works --with-tls --without-__thread.


r~

Re: architecture status, please

[Richard Henderson]

On Thu, Feb 20, 2003 at 11:35:45AM -0800, Richard Henderson wrote:
> Alpha works --with-tls --without-__thread.

Also --with-__thread.


r~

Re: architecture status, please

[Philip Blundell]

On Wed, 2003-02-19 at 22:41, Ulrich Drepper wrote:
> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

With the sysdep.h patch I sent earlier, Arm seems to be working at least
as well as it did in 2.3.1.  "make check" passes with no errors other
than the normal ones relating to floating point.

p.

unwind info fix for ia64

[David Mosberger]

Here is a small bug-fix for libc's __syscall_error to get the unwind
info correct.  Did "make check" afterwards and ran a test program to
verify that unwinding works correctly now for this function.

	--david

2003-02-24    <davidm@hpl.hp.com>

	* sysdeps/unix/sysv/linux/ia64/sysdep.S (__syscall_error): Fix
	unwind info.

Index: sysdeps/unix/sysv/linux/ia64/sysdep.S
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/sysdep.S,v
retrieving revision 1.5
diff -u -r1.5 sysdep.S
--- sysdeps/unix/sysv/linux/ia64/sysdep.S	11 Oct 2002 10:51:24 -0000	1.5
+++ sysdeps/unix/sysv/linux/ia64/sysdep.S	25 Feb 2003 08:30:31 -0000
@@ -1,4 +1,4 @@
-/* Copyright (C) 1999, 2000, 2001 Free Software Foundation, Inc.
+/* Copyright (C) 1999, 2000, 2001, 2003 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by David Mosberger-Tang <davidm@hpl.hp.com>.
 
@@ -23,18 +23,19 @@
 ENTRY(__syscall_error)
 #ifdef _LIBC_REENTRANT
 	.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(0)
-	alloc	r35=ar.pfs, 0, 4, 0, 0
+	alloc	r33=ar.pfs, 0, 4, 0, 0
 	mov	r32=rp
-	mov	r33=r8
+	.body
+	mov	r35=r8
 	mov	r34=r1
 	;;
-	br.call.sptk.many b0 = __errno_location#
+	br.call.sptk.many b0 = __errno_location
 .Lret0:		/* force new bundle */
-	st4	[r8]=r33
+	st4	[r8]=r35
 	mov	r1=r34
 	mov	rp=r32
 	mov	r8=-1
-	mov	ar.pfs=r35
+	mov	ar.pfs=r33
 #else /* _LIBC_REENTRANT */
 	/*
 	 * Note that the gp has to be set properly for this to work.

Re: unwind info fix for ia64

[Ulrich Drepper]

David Mosberger wrote:
> Here is a small bug-fix for libc's __syscall_error to get the unwind
> info correct.  Did "make check" afterwards and ran a test program to
> verify that unwinding works correctly now for this function.

I've applied the patch.  Thanks,

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: architecture status, please

[Steve Munroe]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

Ulrich Drepper writes:

> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

powerpc64 was incomplete in 2.3.1 but current libc cvs head is complete 
and functional for non-tls and linuxthreads.

We have a powerpc64 TLS Access ABI for and it looks like the binutils at 
cvs head are stable for powerpc64. I have glibc --with-tls 
--without-__thread working and will be submitting these patches soon.

The powerpc64 gcc changes for __thread are in progress but incomplete. The 
glibc work for --with-__thead will start when I have a working gcc.

[-- Attachment #2: Type: text/html, Size: 977 bytes --]

Re: architecture status, please

[Ulrich Drepper]

Steve Munroe wrote:

> powerpc64 was incomplete in 2.3.1 but current libc cvs head is complete
> and functional for non-tls and linuxthreads.

That's fine.  There is not need to support TLS.  Other releases will follow.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: architecture status, please

[Martin Schwidefsky]

> I think things have stablelized now and we can think about 2.3.2.  Do
> all architectures which worked in 2.3.1 work now?  Are any other
> architectures which didn't work in 2.3.1 close to working with the
> current tree?

s390-32 passed make + make check. There is a small issue with
chown and --enable-kernel=2.4.20. I'll send a patch for this.

s390-64 fails to compile because of an undefined reference to
'__GI___pwrite64'. pread64.c and pwrite64.c are empty files for
64 bit. With a s390-64 specific implementation of pread64/pwrite64
I got it to work but I doubt that this is the way it should be
fixed. Any ideas?

And by the way why is __pwrite64 hidden and __pread64 isn't ?

blue skies,
   Martin