linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] parisc: futex: Use same lock set as lws calls
@ 2011-10-09 20:40 John David Anglin
  2011-10-10 14:30 ` Rolf Eike Beer
  2011-10-17 15:23 ` Domenico Andreoli
  0 siblings, 2 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-09 20:40 UTC (permalink / raw)
  To: linux-parisc; +Cc: jejb, kyle, deller, carlos

In debugging the failure of the glibc tst-cond18 test on parisc, I realized
that futexes need to use the same locks the lws calls.  This fixes all the
pthread 'cond' tests.  Sadly, there are still problems with thread cancellation.

Signed-of-by: John David Anglin <dave.anglin@bell.net>

diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
index 2388bdb..a8d0586 100644
--- a/arch/parisc/include/asm/futex.h
+++ b/arch/parisc/include/asm/futex.h
@@ -8,6 +8,29 @@
 #include <asm/atomic.h>
 #include <asm/errno.h>
 
+/* The following has to match the LWS code in syscall.S.  We have
+   sixteen four-word locks. */
+
+static inline void
+_futex_spin_lock_irqsave (u32 __user *uaddr, unsigned long int *flags)
+{
+  extern u32 lws_lock_start[];
+  long index = ((long)uaddr & 0xf0) >> 2;
+  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
+  local_irq_save(*flags);
+  arch_spin_lock(s);
+}
+
+static inline void
+_futex_spin_unlock_irqrestore (u32 __user *uaddr, unsigned long int *flags)
+{
+  extern u32 lws_lock_start[];
+  long index = ((long)uaddr & 0xf0) >> 2;
+  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
+  arch_spin_unlock(s);
+  local_irq_restore(*flags);
+}
+
 static inline int
 futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 {
@@ -26,7 +49,7 @@ futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 
 	pagefault_disable();
 
-	_atomic_spin_lock_irqsave(uaddr, flags);
+	_futex_spin_lock_irqsave(uaddr, &flags);
 
 	switch (op) {
 	case FUTEX_OP_SET:
@@ -71,7 +94,7 @@ futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 		ret = -ENOSYS;
 	}
 
-	_atomic_spin_unlock_irqrestore(uaddr, flags);
+	_futex_spin_unlock_irqrestore(uaddr, &flags);
 
 	pagefault_enable();
 
@@ -113,7 +136,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 	 * address. This should scale to a couple of CPUs.
 	 */
 
-	_atomic_spin_lock_irqsave(uaddr, flags);
+	_futex_spin_lock_irqsave(uaddr, &flags);
 
 	ret = get_user(val, uaddr);
 
@@ -122,7 +145,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 
 	*uval = val;
 
-	_atomic_spin_unlock_irqrestore(uaddr, flags);
+	_futex_spin_unlock_irqrestore(uaddr, &flags);
 
 	return ret;
 }

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-09 20:40 [PATCH] parisc: futex: Use same lock set as lws calls John David Anglin
@ 2011-10-10 14:30 ` Rolf Eike Beer
  2011-10-10 20:27   ` John David Anglin
  2011-10-17 15:23 ` Domenico Andreoli
  1 sibling, 1 reply; 38+ messages in thread
From: Rolf Eike Beer @ 2011-10-10 14:30 UTC (permalink / raw)
  To: linux-parisc

> In debugging the failure of the glibc tst-cond18 test on parisc, I
> realized
> that futexes need to use the same locks the lws calls.  This fixes all the
> pthread 'cond' tests.  Sadly, there are still problems with thread
> cancellation.
>
> Signed-of-by: John David Anglin <dave.anglin@bell.net>
>
> diff --git a/arch/parisc/include/asm/futex.h
> b/arch/parisc/include/asm/futex.h
> index 2388bdb..a8d0586 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
> @@ -8,6 +8,29 @@
>  #include <asm/atomic.h>
>  #include <asm/errno.h>
>
> +/* The following has to match the LWS code in syscall.S.  We have
> +   sixteen four-word locks. */
> +
> +static inline void
> +_futex_spin_lock_irqsave (u32 __user *uaddr, unsigned long int *flags)
> +{
> +  extern u32 lws_lock_start[];
> +  long index = ((long)uaddr & 0xf0) >> 2;
> +  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
> +  local_irq_save(*flags);
> +  arch_spin_lock(s);
> +}
> +
> +static inline void
> +_futex_spin_unlock_irqrestore (u32 __user *uaddr, unsigned long int
> *flags)
> +{
> +  extern u32 lws_lock_start[];
> +  long index = ((long)uaddr & 0xf0) >> 2;
> +  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
> +  arch_spin_unlock(s);
> +  local_irq_restore(*flags);
> +}
> +
>  static inline int
>  futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
>  {

This needs tabs.

Greetings,

Eike

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-10 14:30 ` Rolf Eike Beer
@ 2011-10-10 20:27   ` John David Anglin
  2011-10-10 20:30     ` James Bottomley
  0 siblings, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-10 20:27 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc

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

On 10-Oct-11, at 10:30 AM, Rolf Eike Beer wrote:

> This needs tabs.

Sorry, linux style isn't what I normally use.  Change has been updated  
with tabs.

Signed-off-by:  John David Anglin  <dave.anglin@bell.net>


[-- Attachment #2: futex.h.d.1 --]
[-- Type: application/octet-stream, Size: 1945 bytes --]

diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
index 2388bdb..7839285 100644
--- a/arch/parisc/include/asm/futex.h
+++ b/arch/parisc/include/asm/futex.h
@@ -8,6 +8,29 @@
 #include <asm/atomic.h>
 #include <asm/errno.h>
 
+/* The following has to match the LWS code in syscall.S.  We have
+   sixteen four-word locks. */
+
+static inline void
+_futex_spin_lock_irqsave (u32 __user *uaddr, unsigned long int *flags)
+{
+	extern u32 lws_lock_start[];
+	long index = ((long)uaddr & 0xf0) >> 2;
+	arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
+	local_irq_save(*flags);
+	arch_spin_lock(s);
+}
+
+static inline void
+_futex_spin_unlock_irqrestore (u32 __user *uaddr, unsigned long int *flags)
+{
+	extern u32 lws_lock_start[];
+	long index = ((long)uaddr & 0xf0) >> 2;
+	arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
+	arch_spin_unlock(s);
+	local_irq_restore(*flags);
+}
+
 static inline int
 futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 {
@@ -26,7 +49,7 @@ futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 
 	pagefault_disable();
 
-	_atomic_spin_lock_irqsave(uaddr, flags);
+	_futex_spin_lock_irqsave(uaddr, &flags);
 
 	switch (op) {
 	case FUTEX_OP_SET:
@@ -71,7 +94,7 @@ futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
 		ret = -ENOSYS;
 	}
 
-	_atomic_spin_unlock_irqrestore(uaddr, flags);
+	_futex_spin_unlock_irqrestore(uaddr, &flags);
 
 	pagefault_enable();
 
@@ -113,7 +136,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 	 * address. This should scale to a couple of CPUs.
 	 */
 
-	_atomic_spin_lock_irqsave(uaddr, flags);
+	_futex_spin_lock_irqsave(uaddr, &flags);
 
 	ret = get_user(val, uaddr);
 
@@ -122,7 +145,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 
 	*uval = val;
 
-	_atomic_spin_unlock_irqrestore(uaddr, flags);
+	_futex_spin_unlock_irqrestore(uaddr, &flags);
 
 	return ret;
 }

[-- Attachment #3: Type: text/plain, Size: 53 bytes --]




Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply related	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-10 20:27   ` John David Anglin
@ 2011-10-10 20:30     ` James Bottomley
  0 siblings, 0 replies; 38+ messages in thread
From: James Bottomley @ 2011-10-10 20:30 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On Mon, 2011-10-10 at 16:27 -0400, John David Anglin wrote:
> On 10-Oct-11, at 10:30 AM, Rolf Eike Beer wrote:
> 
> > This needs tabs.
> 
> Sorry, linux style isn't what I normally use.  Change has been updated  
> with tabs.

Don't worry.  I tend to fix all of this stuff up on import, which I did
this morning when I started it in my testing environment.

James



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-09 20:40 [PATCH] parisc: futex: Use same lock set as lws calls John David Anglin
  2011-10-10 14:30 ` Rolf Eike Beer
@ 2011-10-17 15:23 ` Domenico Andreoli
  2011-10-17 15:47   ` Carlos O'Donell
  1 sibling, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2011-10-17 15:23 UTC (permalink / raw)
  To: John David Anglin; +Cc: linux-parisc, jejb, kyle, deller, carlos, debian-hppa

Hi John,

On Sun, Oct 09, 2011 at 04:40:10PM -0400, John David Anglin wrote:
> In debugging the failure of the glibc tst-cond18 test on parisc, I realized
> that futexes need to use the same locks the lws calls.  This fixes all the
> pthread 'cond' tests.  Sadly, there are still problems with thread cancellation.

I applied your patch to 3.1-rc9 and tried to build Debian eglibc 2.13-21. It
passed tst-cond18 but is hanging on tst-fork1. Is it where you see the thread
cancellation issue?

Thank you for having looked at it.

Regards,
Domenico

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 15:23 ` Domenico Andreoli
@ 2011-10-17 15:47   ` Carlos O'Donell
  2011-10-17 18:10     ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-17 15:47 UTC (permalink / raw)
  To: John David Anglin, linux-parisc, jejb, kyle, deller, carlos,
	debian-hppa

On Mon, Oct 17, 2011 at 11:23 AM, Domenico Andreoli <cavokz@gmail.com> =
wrote:
> Hi John,
>
> On Sun, Oct 09, 2011 at 04:40:10PM -0400, John David Anglin wrote:
>> In debugging the failure of the glibc tst-cond18 test on parisc, I r=
ealized
>> that futexes need to use the same locks the lws calls. =A0This fixes=
 all the
>> pthread 'cond' tests. =A0Sadly, there are still problems with thread=
 cancellation.
>
> I applied your patch to 3.1-rc9 and tried to build Debian eglibc 2.13=
-21. It
> passed tst-cond18 but is hanging on tst-fork1. Is it where you see th=
e thread
> cancellation issue?
>
> Thank you for having looked at it.

The test-fork1 failure is still unexplained and happens intermittently.

The cancellation issues happen in tst-cancel*.

I believe the cancellation issues are toolchain issues and I need to
look into them.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 15:47   ` Carlos O'Donell
@ 2011-10-17 18:10     ` John David Anglin
  2011-10-17 20:55       ` Carlos O'Donell
  2011-10-20  1:47       ` John David Anglin
  0 siblings, 2 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-17 18:10 UTC (permalink / raw)
  To: debian-hppa, linux-parisc

On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
> The test-fork1 failure is still unexplained and happens intermittently.

I have built a lot of unstable on my rp3440.  I think this one causes 
failures in the thread
testsuites of perl, python2.7 and glib2.0.  These are characterized by 
tests hanging.

There is another class of failures.  They typically cause my rp3440 to 
crash due
to cache corruption.  The GCC libgomp and libatomic-ops testsuite seem 
to trigger
this one.  As I have mentioned, it's the libgomp "for" tests that
>
> The cancellation issues happen in tst-cancel*.
>
> I believe the cancellation issues are toolchain issues and I need to
> look into them.
Possibly, this is related to the following bug that I found last week 
building mpfr-3.1.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
A call to __tls_get_addr clobbers first argument of call to mpfr_cache.  
Don't have a
fix at the moment, but there is a simple testcase.

On a different subject, I tried to get udev-172-1 working.  However, 
this breaks bootstrap
due to an invalid argument in a call to inotify_init.  It's somewhat 
timing dependent since
some kernels will boot if they build enough of /dev before udev messes 
up.  In any case,
I believe that Guy Martin posted a patch a year or so ago to correct an 
inconsistency
between the glibc and the kernel for some bit definitions.  I'm thinking 
this may fix the
udev problem.

It appears that this change got lost and didn't make it into the debian 
glibc patch set.
Was a consensus reached on how to fix this inconsistency?

I plan on seeing if I can resolve the GCC mpfr bug, then I want to 
rebuild glibc with
the flag bits fixed.

I also found a GCC ICE compiling udev-172-1 with gcc-4.4.  Gcc-4.5 and 
gcc-4.6 seem
ok.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 18:10     ` John David Anglin
@ 2011-10-17 20:55       ` Carlos O'Donell
  2011-10-17 21:09         ` John David Anglin
  2011-10-20  1:47       ` John David Anglin
  1 sibling, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-17 20:55 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc

On 10/17/2011 2:10 PM, John David Anglin wrote:
> On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
>> The test-fork1 failure is still unexplained and happens intermittently.
> 
> I have built a lot of unstable on my rp3440.  I think this one causes failures in the thread
> testsuites of perl, python2.7 and glib2.0.  These are characterized by tests hanging.
> 
> There is another class of failures.  They typically cause my rp3440 to crash due
> to cache corruption.  The GCC libgomp and libatomic-ops testsuite seem to trigger
> this one.  As I have mentioned, it's the libgomp "for" tests that
>>
>> The cancellation issues happen in tst-cancel*.
>>
>> I believe the cancellation issues are toolchain issues and I need to
>> look into them.
> Possibly, this is related to the following bug that I found last week building mpfr-3.1.0:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
> A call to __tls_get_addr clobbers first argument of call to mpfr_cache.  Don't have a
> fix at the moment, but there is a simple testcase.
> 
> On a different subject, I tried to get udev-172-1 working.  However, this breaks bootstrap
> due to an invalid argument in a call to inotify_init.  It's somewhat timing dependent since
> some kernels will boot if they build enough of /dev before udev messes up.  In any case,
> I believe that Guy Martin posted a patch a year or so ago to correct an inconsistency
> between the glibc and the kernel for some bit definitions.  I'm thinking this may fix the
> udev problem.

What patch is this? I don't remember it. URL?

> It appears that this change got lost and didn't make it into the debian glibc patch set.
> Was a consensus reached on how to fix this inconsistency?
> 
> I plan on seeing if I can resolve the GCC mpfr bug, then I want to rebuild glibc with
> the flag bits fixed.
> 
> I also found a GCC ICE compiling udev-172-1 with gcc-4.4.  Gcc-4.5 and gcc-4.6 seem
> ok.


Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 20:55       ` Carlos O'Donell
@ 2011-10-17 21:09         ` John David Anglin
  2011-10-17 21:57           ` Domenico Andreoli
                             ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-17 21:09 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: debian-hppa, linux-parisc

On 10/17/2011 4:55 PM, Carlos O'Donell wrote:
> On 10/17/2011 2:10 PM, John David Anglin wrote:
>> >  On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
>>> >>  The test-fork1 failure is still unexplained and happens intermittently.
>> >  
>> >  I have built a lot of unstable on my rp3440.  I think this one causes failures in the thread
>> >  testsuites of perl, python2.7 and glib2.0.  These are characterized by tests hanging.
>> >  
>> >  There is another class of failures.  They typically cause my rp3440 to crash due
>> >  to cache corruption.  The GCC libgomp and libatomic-ops testsuite seem to trigger
>> >  this one.  As I have mentioned, it's the libgomp "for" tests that
>>> >>
>>> >>  The cancellation issues happen in tst-cancel*.
>>> >>
>>> >>  I believe the cancellation issues are toolchain issues and I need to
>>> >>  look into them.
>> >  Possibly, this is related to the following bug that I found last week building mpfr-3.1.0:
>> >  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
>> >  A call to __tls_get_addr clobbers first argument of call to mpfr_cache.  Don't have a
>> >  fix at the moment, but there is a simple testcase.
>> >  
>> >  On a different subject, I tried to get udev-172-1 working.  However, this breaks bootstrap
>> >  due to an invalid argument in a call to inotify_init.  It's somewhat timing dependent since
>> >  some kernels will boot if they build enough of /dev before udev messes up.  In any case,
>> >  I believe that Guy Martin posted a patch a year or so ago to correct an inconsistency
>> >  between the glibc and the kernel for some bit definitions.  I'm thinking this may fix the
>> >  udev problem.
> What patch is this? I don't remember it. URL?
>
http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 21:09         ` John David Anglin
@ 2011-10-17 21:57           ` Domenico Andreoli
  2011-10-17 22:28             ` John David Anglin
  2011-10-18  3:01           ` Carlos O'Donell
  2011-10-20 15:35           ` Carlos O'Donell
  2 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2011-10-17 21:57 UTC (permalink / raw)
  To: John David Anglin; +Cc: Carlos O'Donell, debian-hppa, linux-parisc

On Mon, Oct 17, 2011 at 05:09:05PM -0400, John David Anglin wrote:
> On 10/17/2011 4:55 PM, Carlos O'Donell wrote:
> >On 10/17/2011 2:10 PM, John David Anglin wrote:
> >>>  On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
> >>>>>  The test-fork1 failure is still unexplained and happens intermittently.
> >>>  >  I have built a lot of unstable on my rp3440.  I think this
> >>one causes failures in the thread
> >>>  testsuites of perl, python2.7 and glib2.0.  These are characterized by tests hanging.
> >>>  >  There is another class of failures.  They typically cause
> >>my rp3440 to crash due
> >>>  to cache corruption.  The GCC libgomp and libatomic-ops testsuite seem to trigger
> >>>  this one.  As I have mentioned, it's the libgomp "for" tests that
> >>>>>
> >>>>>  The cancellation issues happen in tst-cancel*.
> >>>>>
> >>>>>  I believe the cancellation issues are toolchain issues and I need to
> >>>>>  look into them.
> >>>  Possibly, this is related to the following bug that I found last week building mpfr-3.1.0:
> >>>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
> >>>  A call to __tls_get_addr clobbers first argument of call to mpfr_cache.  Don't have a
> >>>  fix at the moment, but there is a simple testcase.
> >>>  >  On a different subject, I tried to get udev-172-1 working.
> >>However, this breaks bootstrap
> >>>  due to an invalid argument in a call to inotify_init.  It's somewhat timing dependent since
> >>>  some kernels will boot if they build enough of /dev before udev messes up.  In any case,
> >>>  I believe that Guy Martin posted a patch a year or so ago to correct an inconsistency
> >>>  between the glibc and the kernel for some bit definitions.  I'm thinking this may fix the
> >>>  udev problem.
> >What patch is this? I don't remember it. URL?
> >
> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617973

cheers,
Domenico

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 21:57           ` Domenico Andreoli
@ 2011-10-17 22:28             ` John David Anglin
  2011-10-18  9:31               ` Domenico Andreoli
  2011-10-18  9:33               ` Domenico Andreoli
  0 siblings, 2 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-17 22:28 UTC (permalink / raw)
  To: Domenico Andreoli; +Cc: Carlos O'Donell, debian-hppa, linux-parisc


On 17-Oct-11, at 5:57 PM, Domenico Andreoli wrote:

> On Mon, Oct 17, 2011 at 05:09:05PM -0400, John David Anglin wrote:
>> On 10/17/2011 4:55 PM, Carlos O'Donell wrote:
>>> On 10/17/2011 2:10 PM, John David Anglin wrote:
>>>>> On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
>>>>>>> The test-fork1 failure is still unexplained and happens  
>>>>>>> intermittently.
>>>>>> I have built a lot of unstable on my rp3440.  I think this
>>>> one causes failures in the thread
>>>>> testsuites of perl, python2.7 and glib2.0.  These are  
>>>>> characterized by tests hanging.
>>>>>> There is another class of failures.  They typically cause
>>>> my rp3440 to crash due
>>>>> to cache corruption.  The GCC libgomp and libatomic-ops  
>>>>> testsuite seem to trigger
>>>>> this one.  As I have mentioned, it's the libgomp "for" tests that
>>>>>>>
>>>>>>> The cancellation issues happen in tst-cancel*.
>>>>>>>
>>>>>>> I believe the cancellation issues are toolchain issues and I  
>>>>>>> need to
>>>>>>> look into them.
>>>>> Possibly, this is related to the following bug that I found last  
>>>>> week building mpfr-3.1.0:
>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
>>>>> A call to __tls_get_addr clobbers first argument of call to  
>>>>> mpfr_cache.  Don't have a
>>>>> fix at the moment, but there is a simple testcase.
>>>>>> On a different subject, I tried to get udev-172-1 working.
>>>> However, this breaks bootstrap
>>>>> due to an invalid argument in a call to inotify_init.  It's  
>>>>> somewhat timing dependent since
>>>>> some kernels will boot if they build enough of /dev before udev  
>>>>> messes up.  In any case,
>>>>> I believe that Guy Martin posted a patch a year or so ago to  
>>>>> correct an inconsistency
>>>>> between the glibc and the kernel for some bit definitions.  I'm  
>>>>> thinking this may fix the
>>>>> udev problem.
>>> What patch is this? I don't remember it. URL?
>>>
>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617973
>
dave@mx3210:~$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/ 
Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============- 
============================================
ii  libc6          2.13-10        Embedded GNU C Library: Shared  
libraries

Bug was supposed to be fixed in 2.13-0exp4...

This is the console output:

...
Loading, please wait...
mount: mounting udev on /dev failed: No such device
W: devtmpfs not available, falling back to tmpfs for /dev
udevd[834]: inotify_init failed: Invalid argument
udevd[834]: error initializing inotify
Begin: Loading essential drivers ... SCSI subsystem initialized done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ... done.
Gave up waiting for root device. Common problems:
  - Boot args (cat /proc/cmdline)
     - Check rootdelay= (did the system wait long enough?)
     - Check root= (did the system wait for the right device?)
  - Missing modules (cat /proc/modules; ls /dev)
chvt: can't open console
ALERT! /dev/sda5 does not exist. Dropping to a shell!

BusyBox v1.18.4 (Debian 1:1.18.4-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 21:09         ` John David Anglin
  2011-10-17 21:57           ` Domenico Andreoli
@ 2011-10-18  3:01           ` Carlos O'Donell
  2011-10-18  3:21             ` Carlos O'Donell
  2011-10-20 15:35           ` Carlos O'Donell
  2 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-18  3:01 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc

On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>> What patch is this? I don't remember it. URL?
>>
> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html

Thanks! I'll poke at this tomorrow.

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-18  3:01           ` Carlos O'Donell
@ 2011-10-18  3:21             ` Carlos O'Donell
  2011-10-18 21:22               ` Carlos O'Donell
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-18  3:21 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc, Guy Martin

On Mon, Oct 17, 2011 at 11:01 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>> What patch is this? I don't remember it. URL?
>>>
>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>
> Thanks! I'll poke at this tomorrow.

I remember what happened here. I championed the idea that this patch
should be generic for all targets, or at least for all of ports.

Guy was good enough to give it a shot but Ulrich shot it down.

Unfortunately the patch lost momentum and I never applied the original.

I've just applied this patch and I'll run it through some testing.

Guy,

Did you eventually get a version that helped just libc-ports avoid
these issues of header duplication?

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 22:28             ` John David Anglin
@ 2011-10-18  9:31               ` Domenico Andreoli
  2011-10-18  9:33               ` Domenico Andreoli
  1 sibling, 0 replies; 38+ messages in thread
From: Domenico Andreoli @ 2011-10-18  9:31 UTC (permalink / raw)
  To: John David Anglin; +Cc: Carlos O'Donell, debian-hppa, linux-parisc

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

On Tue, Oct 18, 2011 at 12:28 AM, John David Anglin <dave.anglin@bell.net>wrote:

>
> On 17-Oct-11, at 5:57 PM, Domenico Andreoli wrote:
>
>  On Mon, Oct 17, 2011 at 05:09:05PM -0400, John David Anglin wrote:
>>
>>> On 10/17/2011 4:55 PM, Carlos O'Donell wrote:
>>>
>>>> On 10/17/2011 2:10 PM, John David Anglin wrote:
>>>>
>>>>> On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
>>>>>>
>>>>>>> The test-fork1 failure is still unexplained and happens
>>>>>>>> intermittently.
>>>>>>>>
>>>>>>> I have built a lot of unstable on my rp3440.  I think this
>>>>>>>
>>>>>> one causes failures in the thread
>>>>>
>>>>>> testsuites of perl, python2.7 and glib2.0.  These are characterized by
>>>>>> tests hanging.
>>>>>>
>>>>>>> There is another class of failures.  They typically cause
>>>>>>>
>>>>>> my rp3440 to crash due
>>>>>
>>>>>> to cache corruption.  The GCC libgomp and libatomic-ops testsuite seem
>>>>>> to trigger
>>>>>> this one.  As I have mentioned, it's the libgomp "for" tests that
>>>>>>
>>>>>>>
>>>>>>>> The cancellation issues happen in tst-cancel*.
>>>>>>>>
>>>>>>>> I believe the cancellation issues are toolchain issues and I need to
>>>>>>>> look into them.
>>>>>>>>
>>>>>>> Possibly, this is related to the following bug that I found last week
>>>>>> building mpfr-3.1.0:
>>>>>> http://gcc.gnu.org/bugzilla/**show_bug.cgi?id=50691<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691>
>>>>>> A call to __tls_get_addr clobbers first argument of call to
>>>>>> mpfr_cache.  Don't have a
>>>>>> fix at the moment, but there is a simple testcase.
>>>>>>
>>>>>>> On a different subject, I tried to get udev-172-1 working.
>>>>>>>
>>>>>> However, this breaks bootstrap
>>>>>
>>>>>> due to an invalid argument in a call to inotify_init.  It's somewhat
>>>>>> timing dependent since
>>>>>> some kernels will boot if they build enough of /dev before udev messes
>>>>>> up.  In any case,
>>>>>> I believe that Guy Martin posted a patch a year or so ago to correct
>>>>>> an inconsistency
>>>>>> between the glibc and the kernel for some bit definitions.  I'm
>>>>>> thinking this may fix the
>>>>>> udev problem.
>>>>>>
>>>>> What patch is this? I don't remember it. URL?
>>>>
>>>>  http://www.cygwin.com/ml/libc-**ports/2010-08/msg00001.html<http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html>
>>>
>>
>> http://bugs.debian.org/cgi-**bin/bugreport.cgi?bug=617973<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617973>
>>
>>  dave@mx3210:~$ dpkg -l libc6
> Desired=Unknown/Install/**Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/**Unpacked/halF-conf/Half-inst/**
> trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name           Version        Description
> +++-==============-===========**===-==========================**
> ==================
> ii  libc6          2.13-10        Embedded GNU C Library: Shared libraries
>
> Bug was supposed to be fixed in 2.13-0exp4...
>
> This is the console output:
>
> ...
> Loading, please wait...
> mount: mounting udev on /dev failed: No such device
> W: devtmpfs not available, falling back to tmpfs for /dev
> udevd[834]: inotify_init failed: Invalid argument
> udevd[834]: error initializing inotify
> Begin: Loading essential drivers ... SCSI subsystem initialized done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ...
> Begin: Running /scripts/local-top ... done.
> Begin: Waiting for root file system ... done.
> Gave up waiting for root device. Common problems:
>  - Boot args (cat /proc/cmdline)
>    - Check rootdelay= (did the system wait long enough?)
>    - Check root= (did the system wait for the right device?)
>  - Missing modules (cat /proc/modules; ls /dev)
> chvt: can't open console
> ALERT! /dev/sda5 does not exist. Dropping to a shell!
>
> BusyBox v1.18.4 (Debian 1:1.18.4-1) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> /bin/sh: can't access tty; job control turned off
> (initramfs)
>

Unfortunately I've never been able to build eglibc with the supposed fix,
indeed I'm running an hacked udev on libc 2.11.something.

BTW, how did you successfully build it? you said you build a good part of
unstable, I would like to do the same and maybe upload some key packages...

Regards,
Domenico

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 22:28             ` John David Anglin
  2011-10-18  9:31               ` Domenico Andreoli
@ 2011-10-18  9:33               ` Domenico Andreoli
  2011-10-18 14:20                 ` John David Anglin
  1 sibling, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2011-10-18  9:33 UTC (permalink / raw)
  To: John David Anglin; +Cc: Carlos O'Donell, debian-hppa, linux-parisc

On Tue, Oct 18, 2011 at 12:28 AM, John David Anglin
<dave.anglin@bell.net> wrote:
>
> On 17-Oct-11, at 5:57 PM, Domenico Andreoli wrote:
>
>> On Mon, Oct 17, 2011 at 05:09:05PM -0400, John David Anglin wrote:
>>>
>>> On 10/17/2011 4:55 PM, Carlos O'Donell wrote:
>>>>
>>>> On 10/17/2011 2:10 PM, John David Anglin wrote:
>>>>>>
>>>>>> On 10/17/2011 11:47 AM, Carlos O'Donell wrote:
>>>>>>>>
>>>>>>>> The test-fork1 failure is still unexplained and happens interm=
ittently.
>>>>>>>
>>>>>>> I have built a lot of unstable on my rp3440. =A0I think this
>>>>>
>>>>> one causes failures in the thread
>>>>>>
>>>>>> testsuites of perl, python2.7 and glib2.0. =A0These are characte=
rized by tests hanging.
>>>>>>>
>>>>>>> There is another class of failures. =A0They typically cause
>>>>>
>>>>> my rp3440 to crash due
>>>>>>
>>>>>> to cache corruption. =A0The GCC libgomp and libatomic-ops testsu=
ite seem to trigger
>>>>>> this one. =A0As I have mentioned, it's the libgomp "for" tests t=
hat
>>>>>>>>
>>>>>>>> The cancellation issues happen in tst-cancel*.
>>>>>>>>
>>>>>>>> I believe the cancellation issues are toolchain issues and I n=
eed to
>>>>>>>> look into them.
>>>>>>
>>>>>> Possibly, this is related to the following bug that I found last=
 week building mpfr-3.1.0:
>>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D50691
>>>>>> A call to __tls_get_addr clobbers first argument of call to mpfr=
_cache. =A0Don't have a
>>>>>> fix at the moment, but there is a simple testcase.
>>>>>>>
>>>>>>> On a different subject, I tried to get udev-172-1 working.
>>>>>
>>>>> However, this breaks bootstrap
>>>>>>
>>>>>> due to an invalid argument in a call to inotify_init. =A0It's so=
mewhat timing dependent since
>>>>>> some kernels will boot if they build enough of /dev before udev =
messes up. =A0In any case,
>>>>>> I believe that Guy Martin posted a patch a year or so ago to cor=
rect an inconsistency
>>>>>> between the glibc and the kernel for some bit definitions. =A0I'=
m thinking this may fix the
>>>>>> udev problem.
>>>>
>>>> What patch is this? I don't remember it. URL?
>>>>
>>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D617973
>>
> dave@mx3210:~$ dpkg -l libc6
> Desired=3DUnknown/Install/Remove/Purge/Hold
> | Status=3DNot/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWai=
t/Trig-pend
> |/ Err?=3D(none)/Reinst-required (Status,Err: uppercase=3Dbad)
> ||/ Name =A0 =A0 =A0 =A0 =A0 Version =A0 =A0 =A0 =A0Description
> +++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> ii =A0libc6 =A0 =A0 =A0 =A0 =A02.13-10 =A0 =A0 =A0 =A0Embedded GNU C =
Library: Shared libraries
>
> Bug was supposed to be fixed in 2.13-0exp4...
>
> This is the console output:
>
> ...
> Loading, please wait...
> mount: mounting udev on /dev failed: No such device
> W: devtmpfs not available, falling back to tmpfs for /dev
> udevd[834]: inotify_init failed: Invalid argument
> udevd[834]: error initializing inotify
> Begin: Loading essential drivers ... SCSI subsystem initialized done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ...
> Begin: Running /scripts/local-top ... done.
> Begin: Waiting for root file system ... done.
> Gave up waiting for root device. Common problems:
> =A0- Boot args (cat /proc/cmdline)
> =A0 =A0- Check rootdelay=3D (did the system wait long enough?)
> =A0 =A0- Check root=3D (did the system wait for the right device?)
> =A0- Missing modules (cat /proc/modules; ls /dev)
> chvt: can't open console
> ALERT! /dev/sda5 does not exist. Dropping to a shell!
>
> BusyBox v1.18.4 (Debian 1:1.18.4-1) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> /bin/sh: can't access tty; job control turned off
> (initramfs)

Unfortunately I've never been able to build eglibc with the supposed
fix, indeed I'm running an hacked udev on libc 2.11.something.

BTW, how did you successfully build it? you said you build a good part
of unstable, I would like to do the same and maybe upload some key
packages...

Regards,
Domenico
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-18  9:33               ` Domenico Andreoli
@ 2011-10-18 14:20                 ` John David Anglin
  0 siblings, 0 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-18 14:20 UTC (permalink / raw)
  To: Domenico Andreoli; +Cc: Carlos O'Donell, debian-hppa, linux-parisc

On 10/18/2011 5:33 AM, Domenico Andreoli wrote:
> Unfortunately I've never been able to build eglibc with the supposed
> fix, indeed I'm running an hacked udev on libc 2.11.something.
>
> BTW, how did you successfully build it? you said you build a good part
> of unstable, I would like to do the same and maybe upload some key
> packages...
>
The dependency issues have been somewhat tricky.  I recall that I did my 
initial
2.13 build with my own tool chain builds (binutils and gcc).  I wanted 
to ensure that
I had the binutils fix for non equivalent aliases.  There were also some 
compiler
fixes that I wanted.

Carlos sent me his current glibc patch set and I integrated them into 
the 2.13-10
patches.  I could send you my current two patches tonight.  Carlos also 
has these
updates.  This wasn't completely straight forward as there were some 
conflicts
with the existing patch set.  The main goal was to fix a bug in thread stack
allocation (tst-timer1?).

I used 2.13-10 as my starting source for applying Carlos' changes.  I 
had built
2.13-13 previously, but I removed the source.  I had tried building and 
installing
2.13-14.  However, it wouldn't install without breaking my installed 
version of perl.
So, I had to go back to 2.13-10.

Once I had the glibc multiarch support installed, then I built the 
latest unstable
versions of binutils, gcc-4.4, gnat-4.4, gcj-4.4, gcc-4.5, gcc-4.6, 
etc.  I'm still using
gcc-4.4 as my default.

Next, I had to update perl and python.  This involved updating a bunch 
of libraries.
There was more than one dependency loop where I had to force 
installation of a
library because I needed it to build the library that the installation 
depended on.

Part of the problem is I was starting from a system updated to 
testing/unstable.
Many of the "-dev" packages for libraries had disappeared as newer versions
were built and uploaded to the servers.  I couldn't really go back 
without breaking
a huge amount of stuff.

So, I just plunged forward.  It's not really possible to support GCC 
without having
the new stuff in unstable.

I have kept all my .deb files and can provide them if needed.

I had hoped that we would get a buildd going by now.  If we wait much 
longer,
the dependencies will be a killer.

Based on my experience, a fair number of packages need some manual
intervention to get them to build.  For example, with glibc, it probably 
is necessary
to disable testsuite checking.  With perl and python, it may be 
necessary to manually
kill tests that  hang, etc.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-18  3:21             ` Carlos O'Donell
@ 2011-10-18 21:22               ` Carlos O'Donell
  0 siblings, 0 replies; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-18 21:22 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc, Guy Martin

On Mon, Oct 17, 2011 at 11:21 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Mon, Oct 17, 2011 at 11:01 PM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
>> On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>>> What patch is this? I don't remember it. URL?
>>>>
>>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>>
>> Thanks! I'll poke at this tomorrow.
> I've just applied this patch and I'll run it through some testing.

I've verified it matches what we have in the kernel.

I've verified that a make install-headers puts the right headers in
the right locations.

If some final testing looks good I'll commit these patches for hppa in
libc-ports with an an additional Tested-By: for my testing.

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 18:10     ` John David Anglin
  2011-10-17 20:55       ` Carlos O'Donell
@ 2011-10-20  1:47       ` John David Anglin
  2011-10-21 14:49         ` Carlos O'Donell
  1 sibling, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-20  1:47 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc

On 17-Oct-11, at 2:10 PM, John David Anglin wrote:

>>
>> The cancellation issues happen in tst-cancel*.
>>
>> I believe the cancellation issues are toolchain issues and I need to
>> look into them.
> Possibly, this is related to the following bug that I found last  
> week building mpfr-3.1.0:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691
> A call to __tls_get_addr clobbers first argument of call to  
> mpfr_cache.  Don't have a
> fix at the moment, but there is a simple testcase.

I looked at this a bit.  The problem is legitimize_tls_address doesn't  
work properly.
First, GCC doesn't know that the libcall needs r26 and ret0 when the  
__thread variable
is an argument to a call.  Secondly, the implementation of  
__tls_get_addr clobbers
some other call clobbered registers.  I'm thinking the glibc  
implementation might need to
be in assembly language so that the clobbered registers are limited  
(i.e., it needs to
save registers).   This all seems really ugly...

The issues occur in generating PIC code.

Thoughts?

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-17 21:09         ` John David Anglin
  2011-10-17 21:57           ` Domenico Andreoli
  2011-10-18  3:01           ` Carlos O'Donell
@ 2011-10-20 15:35           ` Carlos O'Donell
  2011-10-20 17:57             ` Matt Turner
  2 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-20 15:35 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc, Guy Martin

On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>> What patch is this? I don't remember it. URL?
>>
> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html

This patch is now checked into glibc-ports.

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-20 15:35           ` Carlos O'Donell
@ 2011-10-20 17:57             ` Matt Turner
  2011-10-20 18:11               ` Carlos O'Donell
  0 siblings, 1 reply; 38+ messages in thread
From: Matt Turner @ 2011-10-20 17:57 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: John David Anglin, debian-hppa, linux-parisc, Guy Martin

On Thu, Oct 20, 2011 at 11:35 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>> What patch is this? I don't remember it. URL?
>>>
>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>
> This patch is now checked into glibc-ports.

The authorship is wrong, I think. Guy wrote the patch, didn't he?

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-20 17:57             ` Matt Turner
@ 2011-10-20 18:11               ` Carlos O'Donell
  2011-10-20 18:16                 ` Matt Turner
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-20 18:11 UTC (permalink / raw)
  To: Matt Turner; +Cc: John David Anglin, debian-hppa, linux-parisc, Guy Martin

On 10/20/2011 1:57 PM, Matt Turner wrote:
> On Thu, Oct 20, 2011 at 11:35 AM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
>> On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>>> What patch is this? I don't remember it. URL?
>>>>
>>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>>
>> This patch is now checked into glibc-ports.
> 
> The authorship is wrong, I think. Guy wrote the patch, didn't he?

Correct, I forgot to use --author, but Guy is credited in the ChangeLog.

Can I change this retroactively or is it too late?

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-20 18:11               ` Carlos O'Donell
@ 2011-10-20 18:16                 ` Matt Turner
  0 siblings, 0 replies; 38+ messages in thread
From: Matt Turner @ 2011-10-20 18:16 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: John David Anglin, debian-hppa, linux-parisc, Guy Martin

On Thu, Oct 20, 2011 at 2:11 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On 10/20/2011 1:57 PM, Matt Turner wrote:
>> On Thu, Oct 20, 2011 at 11:35 AM, Carlos O'Donell
>> <carlos@systemhalted.org> wrote:
>>> On Mon, Oct 17, 2011 at 5:09 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>>>> What patch is this? I don't remember it. URL?
>>>>>
>>>> http://www.cygwin.com/ml/libc-ports/2010-08/msg00001.html
>>>
>>> This patch is now checked into glibc-ports.
>>
>> The authorship is wrong, I think. Guy wrote the patch, didn't he?
>
> Correct, I forgot to use --author, but Guy is credited in the ChangeLog.
>
> Can I change this retroactively or is it too late?
>
> Cheers,
> Carlos.

Once it's pushed to a public git repo it's too late.

This also happened last year,
http://www.cygwin.com/ml/libc-ports/2010-02/msg00014.html

Most people use `git am` which fills in the author field directly.
Otherwise, use git commit --author=... or after the patch it committed
but before it's pushed publicly, git commit --amend --author=...

Matt

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-20  1:47       ` John David Anglin
@ 2011-10-21 14:49         ` Carlos O'Donell
  2011-10-21 17:42           ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-21 14:49 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc

On Wed, Oct 19, 2011 at 9:47 PM, John David Anglin <dave.anglin@bell.ne=
t> wrote:
> I looked at this a bit. =A0The problem is legitimize_tls_address does=
n't work
> properly. First, GCC doesn't know that the libcall needs r26 and ret0=
 when the
> __thread variable is an argument to a call. =A0Secondly, the implemen=
tation of __tls_get_addr
> clobbers some other call clobbered registers. =A0I'm thinking the gli=
bc implementation
> might need to be in assembly language so that the clobbered registers=
 are limited (i.e.,
> it needs to save registers). =A0 This all seems really ugly...
>
> The issues occur in generating PIC code.

Yes, __tls_get_addr is a normal C function and follows normal function
register usage.

Why does __tls_get_addr need to be a special function?

Almost all the targets in glibc-ports have C versions of __tls_get_addr=
=2E

=46or example I notice that on Alpha the call to __tls_get_addr is *not=
*
done via a emit_library_call_value, instead they use some emit_insn,
emit_libcall_block and use_reg.

So it looks like they tamper with the register usage via use_reg
before the call to __tls_get_addr?

Another example is Sparc which also uses a custom sequence and
manipulates the used registers.

I think our legitimize_tls_address needs to be rewritten to match
something like what alpha or sparc has, otherwise we are going to run
into trouble trying to get emit_library_call_value to work correctly.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-21 14:49         ` Carlos O'Donell
@ 2011-10-21 17:42           ` John David Anglin
  2011-10-21 18:11             ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-21 17:42 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: debian-hppa, linux-parisc

On 10/21/2011 10:49 AM, Carlos O'Donell wrote:
> On Wed, Oct 19, 2011 at 9:47 PM, John David Anglin<dave.anglin@bell.net>  wrote:
>> I looked at this a bit.  The problem is legitimize_tls_address doesn't work
>> properly. First, GCC doesn't know that the libcall needs r26 and ret0 when the
>> __thread variable is an argument to a call.  Secondly, the implementation of __tls_get_addr
>> clobbers some other call clobbered registers.  I'm thinking the glibc implementation
>> might need to be in assembly language so that the clobbered registers are limited (i.e.,
>> it needs to save registers).   This all seems really ugly...
>>
>> The issues occur in generating PIC code.
> Yes, __tls_get_addr is a normal C function and follows normal function
> register usage.
Yes.  The issue here is expand_call doesn't appear to be aware that 
loading the
address of a __thread variable may require a call.  Thus, it just emits 
an insn to
load r26.  This load is dead because r26 is reloaded for the call to 
__tls_get_addr.

The first argument for the call needs to be saved to a temp, and then 
r26 needs
to be loaded just before the actual call.  This is works fine for normal 
calls.
>
> Why does __tls_get_addr need to be a special function?
>
> Almost all the targets in glibc-ports have C versions of __tls_get_addr.
>
> For example I notice that on Alpha the call to __tls_get_addr is *not*
> done via a emit_library_call_value, instead they use some emit_insn,
> emit_libcall_block and use_reg.
use_reg won't help.  This is attached to the call insn and only comes 
into play
during register allocation.  The problem occurs during rtl expansion.
>
> So it looks like they tamper with the register usage via use_reg
> before the call to __tls_get_addr?
>
> Another example is Sparc which also uses a custom sequence and
> manipulates the used registers.
sparc64 tls support is also broken...  See,
http://www.loria.fr/~zimmerma/software/compilerbugs.html

>
> I think our legitimize_tls_address needs to be rewritten to match
> something like what alpha or sparc has, otherwise we are going to run
> into trouble trying to get emit_library_call_value to work correctly.
>
>

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-21 17:42           ` John David Anglin
@ 2011-10-21 18:11             ` John David Anglin
  2011-10-21 18:15               ` Carlos O'Donell
  0 siblings, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-21 18:11 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: debian-hppa, linux-parisc

On 10/21/2011 1:42 PM, John David Anglin wrote:
> Yes.  The issue here is expand_call doesn't appear to be aware that 
> loading the
> address of a __thread variable may require a call.  Thus, it just 
> emits an insn to
> load r26.  This load is dead because r26 is reloaded for the call to 
> __tls_get_addr.
It appears this may be caused by treating TLS symbols as legitimate 
constants.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-21 18:11             ` John David Anglin
@ 2011-10-21 18:15               ` Carlos O'Donell
  2011-10-30 15:04                 ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-21 18:15 UTC (permalink / raw)
  To: John David Anglin; +Cc: debian-hppa, linux-parisc

On Fri, Oct 21, 2011 at 2:11 PM, John David Anglin <dave.anglin@bell.ne=
t> wrote:
> On 10/21/2011 1:42 PM, John David Anglin wrote:
>>
>> Yes. =A0The issue here is expand_call doesn't appear to be aware tha=
t
>> loading the
>> address of a __thread variable may require a call. =A0Thus, it just =
emits an
>> insn to
>> load r26. =A0This load is dead because r26 is reloaded for the call =
to
>> __tls_get_addr.
>
> It appears this may be caused by treating TLS symbols as legitimate
> constants.

Which they are not in any of the *_DYNAMIC modes, because the dynamic
linker is involved in their placement.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-21 18:15               ` Carlos O'Donell
@ 2011-10-30 15:04                 ` John David Anglin
  2011-10-30 15:31                   ` Rolf Eike Beer
  0 siblings, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-30 15:04 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: debian-hppa, linux-parisc

On 21-Oct-11, at 2:15 PM, Carlos O'Donell wrote:

> On Fri, Oct 21, 2011 at 2:11 PM, John David Anglin <dave.anglin@bell.net 
> > wrote:
>> On 10/21/2011 1:42 PM, John David Anglin wrote:
>>>
>>> Yes.  The issue here is expand_call doesn't appear to be aware that
>>> loading the
>>> address of a __thread variable may require a call.  Thus, it just  
>>> emits an
>>> insn to
>>> load r26.  This load is dead because r26 is reloaded for the call to
>>> __tls_get_addr.
>>
>> It appears this may be caused by treating TLS symbols as legitimate
>> constants.
>
> Which they are not in any of the *_DYNAMIC modes, because the dynamic
> linker is involved in their placement.


This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6 branches.   
libmpfr4-3.1.0
now passes all tests.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-30 15:04                 ` John David Anglin
@ 2011-10-30 15:31                   ` Rolf Eike Beer
  2011-10-30 16:13                     ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Rolf Eike Beer @ 2011-10-30 15:31 UTC (permalink / raw)
  To: linux-parisc

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

John David Anglin wrote:

> This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6 branches.
> libmpfr4-3.1.0 now passes all tests.

Can we get a link to a bug or a commit so we could easily put this into the 
gentoo patchset for local usage until a new version is released?

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-30 15:31                   ` Rolf Eike Beer
@ 2011-10-30 16:13                     ` John David Anglin
  2011-10-31  0:21                       ` Carlos O'Donell
  0 siblings, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-30 16:13 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc

On 30-Oct-11, at 11:31 AM, Rolf Eike Beer wrote:

> John David Anglin wrote:
>
>> This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6 branches.
>> libmpfr4-3.1.0 now passes all tests.
>
> Can we get a link to a bug or a commit so we could easily put this  
> into the
> gentoo patchset for local usage until a new version is released?


The trunk patch is on the gcc-patches list:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02758.html

There are two variants of the patch:
http://gcc.gnu.org/viewcvs?view=revision&revision=180655
http://gcc.gnu.org/viewcvs?view=revision&revision=180662

The first is for 4.7.  The latter applies to 4.4, 4.5 and 4.6.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-30 16:13                     ` John David Anglin
@ 2011-10-31  0:21                       ` Carlos O'Donell
  2011-10-31  1:36                         ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-10-31  0:21 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On Sun, Oct 30, 2011 at 12:13 PM, John David Anglin
<dave.anglin@bell.net> wrote:
> On 30-Oct-11, at 11:31 AM, Rolf Eike Beer wrote:
>
>> John David Anglin wrote:
>>
>>> This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6 branche=
s.
>>> libmpfr4-3.1.0 now passes all tests.
>>
>> Can we get a link to a bug or a commit so we could easily put this i=
nto
>> the
>> gentoo patchset for local usage until a new version is released?
>
>
> The trunk patch is on the gcc-patches list:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02758.html
>
> There are two variants of the patch:
> http://gcc.gnu.org/viewcvs?view=3Drevision&revision=3D180655
> http://gcc.gnu.org/viewcvs?view=3Drevision&revision=3D180662
>
> The first is for 4.7. =A0The latter applies to 4.4, 4.5 and 4.6.

Awesome! Great work Dave! :-)

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31  0:21                       ` Carlos O'Donell
@ 2011-10-31  1:36                         ` John David Anglin
  2011-10-31  9:41                           ` Domenico Andreoli
  2011-11-01  2:15                           ` Carlos O'Donell
  0 siblings, 2 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-31  1:36 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Rolf Eike Beer, linux-parisc

On 30-Oct-11, at 8:21 PM, Carlos O'Donell wrote:

> On Sun, Oct 30, 2011 at 12:13 PM, John David Anglin
> <dave.anglin@bell.net> wrote:
>> On 30-Oct-11, at 11:31 AM, Rolf Eike Beer wrote:
>>
>>> John David Anglin wrote:
>>>
>>>> This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6  
>>>> branches.
>>>> libmpfr4-3.1.0 now passes all tests.
>>>
>>> Can we get a link to a bug or a commit so we could easily put this  
>>> into
>>> the
>>> gentoo patchset for local usage until a new version is released?
>>
>>
>> The trunk patch is on the gcc-patches list:
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02758.html
>>
>> There are two variants of the patch:
>> http://gcc.gnu.org/viewcvs?view=revision&revision=180655
>> http://gcc.gnu.org/viewcvs?view=revision&revision=180662
>>
>> The first is for 4.7.  The latter applies to 4.4, 4.5 and 4.6.
>
> Awesome! Great work Dave! :-)

Thanks, but this fix wasn't that hard...  I had a little trouble with  
the testing
due to other issues.  Many GCC bugs are much harder.  Things are easy
when the compilation bug is clear.

I integrated Guy's patch into debian 2.13-10 today and I was going to do
a build, but then I discovered it builds using 4.4.  So, I patched 4.4  
with the
above change, and will rebuild 2.13 when it's done.  Hopefully, this  
will
fix the udev bug which is blocking many python builds.  I'm interested  
to
see if the glibc testsuite results will be better.

It's a bit unclear how extensively TLS variables are used, but maybe  
fixing
this will make it easier to resolve the remaining pthread bugs.

I've been wondering how much is left to install to glibc head?

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31  1:36                         ` John David Anglin
@ 2011-10-31  9:41                           ` Domenico Andreoli
  2011-10-31 12:28                             ` John David Anglin
  2011-10-31 23:26                             ` John David Anglin
  2011-11-01  2:15                           ` Carlos O'Donell
  1 sibling, 2 replies; 38+ messages in thread
From: Domenico Andreoli @ 2011-10-31  9:41 UTC (permalink / raw)
  To: John David Anglin
  Cc: Carlos O'Donell, Rolf Eike Beer, linux-parisc, debian-hppa

On Sun, Oct 30, 2011 at 09:36:05PM -0400, John David Anglin wrote:
> 
> I integrated Guy's patch into debian 2.13-10 today and I was going to do
> a build, but then I discovered it builds using 4.4.  So, I patched
> 4.4 with the
> above change, and will rebuild 2.13 when it's done.  Hopefully, this
> will
> fix the udev bug which is blocking many python builds.  I'm
> interested to
> see if the glibc testsuite results will be better.

I would like to redo the exercise on my j5600, are you building Debian
packages? Could you please share the sources? Thank you.

Regards,
Domenico

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31  9:41                           ` Domenico Andreoli
@ 2011-10-31 12:28                             ` John David Anglin
  2011-10-31 23:26                             ` John David Anglin
  1 sibling, 0 replies; 38+ messages in thread
From: John David Anglin @ 2011-10-31 12:28 UTC (permalink / raw)
  To: Domenico Andreoli
  Cc: Carlos O'Donell, Rolf Eike Beer, linux-parisc, debian-hppa

On 31-Oct-11, at 5:41 AM, Domenico Andreoli wrote:

> On Sun, Oct 30, 2011 at 09:36:05PM -0400, John David Anglin wrote:
>>
>> I integrated Guy's patch into debian 2.13-10 today and I was going  
>> to do
>> a build, but then I discovered it builds using 4.4.  So, I patched
>> 4.4 with the
>> above change, and will rebuild 2.13 when it's done.  Hopefully, this
>> will
>> fix the udev bug which is blocking many python builds.  I'm
>> interested to
>> see if the glibc testsuite results will be better.
>
> I would like to redo the exercise on my j5600, are you building Debian
> packages? Could you please share the sources? Thank you.

I am building Debian unstable source packages.  I am close to catching
up the areas that I use.

Except for the recent GCC TLS fix and three eglibc packages, I have been
using unmodified upstream stream sources.  I may have hacked one or two,
but the change was obvious.

There were instructions posted on debian-hppa a few months ago on
adding debian-ports to your sources list file.

  I don't generally retain the debian source files due to limited disk  
space.
What I could make available is my .deb files.

I will post the eglibc patches when I confirm that the latest update  
fixes
the udev bug.  I also need to rebuild perl and check its status.  Moving
to the current eglibc version may break old versions of perl.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31  9:41                           ` Domenico Andreoli
  2011-10-31 12:28                             ` John David Anglin
@ 2011-10-31 23:26                             ` John David Anglin
  2011-11-01  9:15                               ` Domenico Andreoli
  1 sibling, 1 reply; 38+ messages in thread
From: John David Anglin @ 2011-10-31 23:26 UTC (permalink / raw)
  To: Domenico Andreoli
  Cc: Carlos O'Donell, Rolf Eike Beer, linux-parisc, debian-hppa

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

On 31-Oct-11, at 5:41 AM, Domenico Andreoli wrote:

> I would like to redo the exercise on my j5600, are you building Debian
> packages? Could you please share the sources? Thank you.

Attached are the hppa libc6 patches that I'm using.  The local-stack- 
grows-up.diff patch needs
to be removed first, then the patches applied in order of date using  
quilt.

The last change resolves the udev bug.

I will send you offline the eglibc_2.13-10.dsc  and the  
eglibc_2.13-10.diff.gz.  The
eglibc_2.13.orig.tar.gz file should still be available.

Dave
--
John David Anglin	dave.anglin@bell.net


[-- Attachment #2: ports-2011-08-31.diff --]
[-- Type: application/octet-stream, Size: 24762 bytes --]

Index: eglibc-2.13/ports/ChangeLog.hppa
===================================================================
--- eglibc-2.13.orig/ports/ChangeLog.hppa	2011-09-04 14:13:02.000000000 -0400
+++ eglibc-2.13/ports/ChangeLog.hppa	2011-09-04 14:20:23.000000000 -0400
@@ -1,3 +1,8 @@
+2010-10-29  Carlos O'Donell  <carlos@codesourcery.com>
+
+	* sysdeps/hppa/dl-machine.h: Update copyright year.
+	(ELF_MACHINE_BEFORE_RTLD_RELOC): Call _dl_fptr_init.
+
 2010-06-24  Carlos O'Donell  <carlos@codesourcery.com>
 
 	* sysdeps/unix/sysv/linux/hppa/nptl/pt-vfork.S: Only create stack 
Index: eglibc-2.13/ports/sysdeps/hppa/configure
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/configure	2011-09-04 14:13:32.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/configure	2011-09-04 14:34:35.000000000 -0400
@@ -1,19 +1,101 @@
+
+# as_fn_set_status STATUS
+# -----------------------
+# Set $? to STATUS, without forking.
+as_fn_set_status ()
+{
+  return $1
+} # as_fn_set_status
+
+# as_fn_exit STATUS
+# -----------------
+# Exit the shell with STATUS, even in a "trap 0" or "set -e" context.
+as_fn_exit ()
+{
+  set +e
+  as_fn_set_status $1
+  exit $1
+} # as_fn_exit
+if expr a : '\(a\)' >/dev/null 2>&1 &&
+   test "X`expr 00001 : '.*\(...\)'`" = X001; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+if (basename -- /) >/dev/null 2>&1 && test "X`basename -- / 2>&1`" = "X/"; then
+  as_basename=basename
+else
+  as_basename=false
+fi
+
+as_me=`$as_basename -- "$0" ||
+$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
+        X"$0" : 'X\(//\)$' \| \
+        X"$0" : 'X\(/\)' \| . 2>/dev/null ||
+$as_echo X/"$0" |
+    sed '/^.*\/\([^/][^/]*\)\/*$/{
+           s//\1/
+           q
+         }
+         /^X\/\(\/\/\)$/{
+           s//\1/
+           q
+         }
+         /^X\/\(\/\).*/{
+           s//\1/
+           q
+         }
+         s/.*/./; q'`
+
+
+  as_lineno_1=$LINENO as_lineno_1a=$LINENO
+  as_lineno_2=$LINENO as_lineno_2a=$LINENO
+  eval 'test "x$as_lineno_1'$as_run'" != "x$as_lineno_2'$as_run'" &&
+  test "x`expr $as_lineno_1'$as_run' + 1`" = "x$as_lineno_2'$as_run'"' || {
+  # Blame Lee E. McMahon (1931-1989) for sed's syntax.  :-)
+  sed -n '
+    p
+    /[$]LINENO/=
+  ' <$as_myself |
+    sed '
+      s/[$]LINENO.*/&-/
+      t lineno
+      b
+      :lineno
+      N
+      :loop
+      s/[$]LINENO\([^'$as_cr_alnum'_].*\n\)\(.*\)/\2\1\2/
+      t loop
+      s/-\n.*//
+    ' >$as_me.lineno &&
+  chmod +x "$as_me.lineno" ||
+    { $as_echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2; as_fn_exit 1; }
+
+  # Don't try to exec as it changes $[0], causing all sort of problems
+  # (the dirname of $[0] is not the place where we might find the
+  # original and so on.  Autoconf is especially sensitive to this).
+  . "./$as_me.lineno"
+  # Exit status is that of the last command.
+  exit
+}
+
 # This file is generated from configure.in by Autoconf.  DO NOT EDIT!
 
-{ $as_echo "$as_me:$LINENO: checking for assembler line separator" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for assembler line separator" >&5
 $as_echo_n "checking for assembler line separator... " >&6; }
-if test "${libc_cv_asm_line_sep+set}" = set; then
+if test "${libc_cv_asm_line_sep+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat > conftest.s <<EOF
 nop ; is_old_puffin
 EOF
 if { ac_try='${CC-cc} -c $ASFLAGS conftest.s 1>&5'
-  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
   (eval $ac_try) 2>&5
   ac_status=$?
-  $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
-  (exit $ac_status); }; }; then
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }; then
   libc_cv_asm_line_sep='!'
 else
   if test -z "$enable_hacker_mode"; then
@@ -25,7 +107,7 @@
 fi
 rm -f conftest*
 fi
-{ $as_echo "$as_me:$LINENO: result: $libc_cv_asm_line_sep" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_asm_line_sep" >&5
 $as_echo "$libc_cv_asm_line_sep" >&6; }
 cat >>confdefs.h <<_ACEOF
 #define ASM_LINE_SEP $libc_cv_asm_line_sep
Index: eglibc-2.13/ports/sysdeps/hppa/dl-fptr.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/dl-fptr.h	2011-09-04 14:14:04.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/dl-fptr.h	2011-09-04 14:20:23.000000000 -0400
@@ -22,6 +22,9 @@
 
 #include <sysdeps/generic/dl-fptr.h>
 
+/* Initialize function pointer code. Call before relocation processing.  */
+extern void _dl_fptr_init (void);
+
 /* There are currently 33 dynamic symbols in ld.so.
    ELF_MACHINE_BOOT_FPTR_TABLE_LEN needs to be at least that big.  */
 #define ELF_MACHINE_BOOT_FPTR_TABLE_LEN 64	
Index: eglibc-2.13/ports/sysdeps/hppa/dl-machine.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/dl-machine.h	2011-09-04 14:14:30.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/dl-machine.h	2011-09-04 14:20:23.000000000 -0400
@@ -1,6 +1,5 @@
 /* Machine-dependent ELF dynamic relocation inline functions.  PA-RISC version.
-   Copyright (C) 1995-1997,1999-2003
-	Free Software Foundation, Inc.
+   Copyright (C) 1995-1997,1999-2003, 2010 Free Software Foundation, Inc.
    Contributed by David Huggins-Daines <dhd@debian.org>
    This file is part of the GNU C Library.
 
Index: eglibc-2.13/ports/sysdeps/hppa/dl-tls.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/dl-tls.h	2011-09-04 14:14:57.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/dl-tls.h	2011-09-04 14:20:23.000000000 -0400
@@ -1,5 +1,5 @@
 /* Thread-local storage handling in the ELF dynamic linker.  hppa version.
-   Copyright (C) 2003 Free Software Foundation, Inc.
+   Copyright (C) 2003, 2011 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -27,3 +27,6 @@
 
 
 extern void *__tls_get_addr (tls_index *ti);
+
+/* Value used for dtv entries for which the allocation is delayed.  */
+#define TLS_DTV_UNALLOCATED	((void *) -1l)
Index: eglibc-2.13/ports/sysdeps/hppa/elf/configure
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/elf/configure	2011-09-04 14:15:24.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/elf/configure	2011-09-04 14:45:59.000000000 -0400
@@ -1,12 +1,94 @@
+
+# as_fn_set_status STATUS
+# -----------------------
+# Set $? to STATUS, without forking.
+as_fn_set_status ()
+{
+  return $1
+} # as_fn_set_status
+
+# as_fn_exit STATUS
+# -----------------
+# Exit the shell with STATUS, even in a "trap 0" or "set -e" context.
+as_fn_exit ()
+{
+  set +e
+  as_fn_set_status $1
+  exit $1
+} # as_fn_exit
+if expr a : '\(a\)' >/dev/null 2>&1 &&
+   test "X`expr 00001 : '.*\(...\)'`" = X001; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+if (basename -- /) >/dev/null 2>&1 && test "X`basename -- / 2>&1`" = "X/"; then
+  as_basename=basename
+else
+  as_basename=false
+fi
+
+as_me=`$as_basename -- "$0" ||
+$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
+        X"$0" : 'X\(//\)$' \| \
+        X"$0" : 'X\(/\)' \| . 2>/dev/null ||
+$as_echo X/"$0" |
+    sed '/^.*\/\([^/][^/]*\)\/*$/{
+           s//\1/
+           q
+         }
+         /^X\/\(\/\/\)$/{
+           s//\1/
+           q
+         }
+         /^X\/\(\/\).*/{
+           s//\1/
+           q
+         }
+         s/.*/./; q'`
+
+
+  as_lineno_1=$LINENO as_lineno_1a=$LINENO
+  as_lineno_2=$LINENO as_lineno_2a=$LINENO
+  eval 'test "x$as_lineno_1'$as_run'" != "x$as_lineno_2'$as_run'" &&
+  test "x`expr $as_lineno_1'$as_run' + 1`" = "x$as_lineno_2'$as_run'"' || {
+  # Blame Lee E. McMahon (1931-1989) for sed's syntax.  :-)
+  sed -n '
+    p
+    /[$]LINENO/=
+  ' <$as_myself |
+    sed '
+      s/[$]LINENO.*/&-/
+      t lineno
+      b
+      :lineno
+      N
+      :loop
+      s/[$]LINENO\([^'$as_cr_alnum'_].*\n\)\(.*\)/\2\1\2/
+      t loop
+      s/-\n.*//
+    ' >$as_me.lineno &&
+  chmod +x "$as_me.lineno" ||
+    { $as_echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2; as_fn_exit 1; }
+
+  # Don't try to exec as it changes $[0], causing all sort of problems
+  # (the dirname of $[0] is not the place where we might find the
+  # original and so on.  Autoconf is especially sensitive to this).
+  . "./$as_me.lineno"
+  # Exit status is that of the last command.
+  exit
+}
+
 # This file is generated from configure.in by Autoconf.  DO NOT EDIT!
  # Local configure fragment for sysdeps/hppa/elf.
 
 if test "$usetls" != no; then
 # Check for support of thread-local storage handling in assembler and
 # linker.
-{ $as_echo "$as_me:$LINENO: checking for hppa TLS support" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for hppa TLS support" >&5
 $as_echo_n "checking for hppa TLS support... " >&6; }
-if test "${libc_cv_hppa_tls+set}" = set; then
+if test "${libc_cv_hppa_tls+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat > conftest.s <<\EOF
@@ -41,23 +123,21 @@
 ; Done all the TLS tests.
 EOF
 if { ac_try='${CC-cc} -c $CFLAGS conftest.s 1>&5'
-  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
   (eval $ac_try) 2>&5
   ac_status=$?
-  $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
-  (exit $ac_status); }; }; then
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }; then
   libc_cv_hppa_tls=yes
 else
   libc_cv_hppa_tls=no
 fi
 rm -f conftest*
 fi
-{ $as_echo "$as_me:$LINENO: result: $libc_cv_hppa_tls" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_hppa_tls" >&5
 $as_echo "$libc_cv_hppa_tls" >&6; }
 if test $libc_cv_hppa_tls = yes; then
-  cat >>confdefs.h <<\_ACEOF
-#define HAVE_TLS_SUPPORT 1
-_ACEOF
+  $as_echo "#define HAVE_TLS_SUPPORT 1" >>confdefs.h
 
 fi
 fi
Index: eglibc-2.13/ports/sysdeps/hppa/fpu/fegetenv.c
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/fpu/fegetenv.c	2011-09-04 14:15:52.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/fpu/fegetenv.c	2011-09-04 14:20:23.000000000 -0400
@@ -1,5 +1,5 @@
 /* Store current floating-point environment.
-   Copyright (C) 2000 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2011 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by David Huggins-Daines <dhd@debian.org>, 2000
 
Index: eglibc-2.13/ports/sysdeps/hppa/fpu/feupdateenv.c
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/fpu/feupdateenv.c	2011-09-04 14:16:18.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/fpu/feupdateenv.c	2011-09-04 14:20:23.000000000 -0400
@@ -1,5 +1,5 @@
 /* Install given floating-point environment and raise exceptions.
-   Copyright (C) 2000 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2011 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by David Huggins-Daines <dhd@debian.org>, 2000
 
Index: eglibc-2.13/ports/sysdeps/hppa/fpu/ftestexcept.c
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/fpu/ftestexcept.c	2011-09-04 14:16:49.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/fpu/ftestexcept.c	2011-09-04 14:20:23.000000000 -0400
@@ -1,5 +1,5 @@
 /* Test exception in current environment.
-   Copyright (C) 2000 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2011 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by David Huggins-Daines <dhd@debian.org>, 2000
 
Index: eglibc-2.13/ports/sysdeps/hppa/stackinfo.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/hppa/stackinfo.h	2011-09-04 14:17:22.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/hppa/stackinfo.h	2011-09-04 14:20:23.000000000 -0400
@@ -22,6 +22,12 @@
 #ifndef _STACKINFO_H
 #define _STACKINFO_H	1
 
+#include <elf.h>
+
+/* Default to an executable stack.  PF_X can be overridden if PT_GNU_STACK is
+ * present, but it is presumed absent.  */
+#define DEFAULT_STACK_PERMS (PF_R|PF_W|PF_X)
+
 /* On PA the stack grows up.  */
 #define _STACK_GROWS_UP	1
 
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h	2011-09-04 14:17:42.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h	2011-09-04 14:20:23.000000000 -0400
@@ -1,5 +1,5 @@
-/* O_*, F_*, FD_* bit values for Linux/HPPA.
-   Copyright (C) 1995,1996,1997,1998,1999,2000,2002,2004
+/* O_*, F_*, FD_* bit values for Linux.
+   Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2002, 2004, 2010
    Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
@@ -29,7 +29,7 @@
 
 
 /* open/fcntl - O_SYNC is only implemented on blocks devices and on files
-   located on an ext2 file system */
+   located on a few file systems.  */
 #define O_ACCMODE	   0003
 #define O_RDONLY	     00
 #define O_WRONLY	     01
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h	2011-09-04 14:18:10.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h	2011-09-04 14:20:23.000000000 -0400
@@ -61,11 +61,53 @@
    
 # undef PSEUDO
 # define PSEUDO(name, syscall_name, args)				\
+	ENTRY (__##syscall_name##_nocancel)				\
+	DOARGS_##args					ASM_LINE_SEP	\
+	stwm TREG, 64(%sp)				ASM_LINE_SEP	\
+	.cfi_offset TREG, 0				ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset 64			ASM_LINE_SEP	\
+	stw %sp, -4(%sp)				ASM_LINE_SEP	\
+	.cfi_offset 30, -4				ASM_LINE_SEP	\
+	stw %r19, -32(%sp)				ASM_LINE_SEP	\
+	.cfi_offset 19, -32				ASM_LINE_SEP	\
+	/* Save r19 */					ASM_LINE_SEP	\
+	SAVE_PIC(TREG)					ASM_LINE_SEP	\
+	/* Do syscall, delay loads # */			ASM_LINE_SEP	\
+	ble  0x100(%sr2,%r0)				ASM_LINE_SEP	\
+	ldi SYS_ify (syscall_name), %r20 /* delay */	ASM_LINE_SEP	\
+	ldi NO_ERROR,%r1				ASM_LINE_SEP	\
+	cmpb,>>=,n %r1,%ret0,L(pre_nc_end)		ASM_LINE_SEP	\
+	/* Restore r19 from TREG */			ASM_LINE_SEP	\
+	LOAD_PIC(TREG) /* delay */			ASM_LINE_SEP	\
+	SYSCALL_ERROR_HANDLER				ASM_LINE_SEP	\
+	/* Use TREG for temp storage */			ASM_LINE_SEP	\
+	copy %ret0, TREG /* delay */			ASM_LINE_SEP	\
+	/* OPTIMIZE: Don't reload r19 */		ASM_LINE_SEP	\
+	/* do a -1*syscall_ret0 */			ASM_LINE_SEP	\
+	sub %r0, TREG, TREG				ASM_LINE_SEP	\
+	/* Store into errno location */			ASM_LINE_SEP	\
+	stw TREG, 0(%sr0,%ret0)				ASM_LINE_SEP	\
+	/* return -1 as error */			ASM_LINE_SEP	\
+	ldi -1, %ret0					ASM_LINE_SEP	\
+L(pre_nc_end):						ASM_LINE_SEP	\
+	/* No need to LOAD_PIC */			ASM_LINE_SEP	\
+	/* Undo frame */				ASM_LINE_SEP	\
+	ldwm -64(%sp),TREG				ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset -64			ASM_LINE_SEP	\
+	/* Restore rp before exit */			ASM_LINE_SEP	\
+	ldw -20(%sp), %rp				ASM_LINE_SEP	\
+	.cfi_restore 2					ASM_LINE_SEP	\
+	ret						ASM_LINE_SEP	\
+	END(__##syscall_name##_nocancel)		ASM_LINE_SEP	\
+	/**********************************************/ASM_LINE_SEP	\
 	ENTRY (name)							\
 	DOARGS_##args					ASM_LINE_SEP	\
 	stwm TREG, 64(%sp)				ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset 64			ASM_LINE_SEP	\
 	stw %sp, -4(%sp)				ASM_LINE_SEP	\
+	.cfi_offset 30, -4				ASM_LINE_SEP	\
 	stw %r19, -32(%sp)				ASM_LINE_SEP	\
+	.cfi_offset 19, -32				ASM_LINE_SEP	\
 	/* Done setting up frame, continue... */	ASM_LINE_SEP	\
 	SINGLE_THREAD_P					ASM_LINE_SEP	\
 	cmpib,<>,n 0,%ret0,L(pseudo_cancel)		ASM_LINE_SEP	\
@@ -128,26 +170,40 @@
 	/* No need to LOAD_PIC */			ASM_LINE_SEP	\
 	/* Undo frame */				ASM_LINE_SEP	\
 	ldwm -64(%sp),TREG				ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset -64			ASM_LINE_SEP	\
 	/* Restore rp before exit */			ASM_LINE_SEP	\
-	ldw -20(%sp), %rp				ASM_LINE_SEP
+	ldw -20(%sp), %rp				ASM_LINE_SEP	\
+	.cfi_restore 2					ASM_LINE_SEP
 
 /* Save arguments into our frame */
 # define PUSHARGS_0	/* nothing to do */
-# define PUSHARGS_1	PUSHARGS_0 stw %r26, -36(%sr0,%sp)	ASM_LINE_SEP
-# define PUSHARGS_2	PUSHARGS_1 stw %r25, -40(%sr0,%sp)	ASM_LINE_SEP
-# define PUSHARGS_3	PUSHARGS_2 stw %r24, -44(%sr0,%sp)	ASM_LINE_SEP
-# define PUSHARGS_4	PUSHARGS_3 stw %r23, -48(%sr0,%sp)	ASM_LINE_SEP
-# define PUSHARGS_5	PUSHARGS_4 stw %r22, -52(%sr0,%sp)	ASM_LINE_SEP 
-# define PUSHARGS_6	PUSHARGS_5 stw %r21, -56(%sr0,%sp)	ASM_LINE_SEP
+# define PUSHARGS_1	PUSHARGS_0 stw %r26, -36(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 26, -36			ASM_LINE_SEP
+# define PUSHARGS_2	PUSHARGS_1 stw %r25, -40(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 25, -40			ASM_LINE_SEP
+# define PUSHARGS_3	PUSHARGS_2 stw %r24, -44(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 24, -44			ASM_LINE_SEP
+# define PUSHARGS_4	PUSHARGS_3 stw %r23, -48(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 23, -48			ASM_LINE_SEP
+# define PUSHARGS_5	PUSHARGS_4 stw %r22, -52(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 22, -52			ASM_LINE_SEP
+# define PUSHARGS_6	PUSHARGS_5 stw %r21, -56(%sr0,%sp)	ASM_LINE_SEP	\
+			.cfi_offset 21, -56			ASM_LINE_SEP
 
 /* Bring them back from the stack */
 # define POPARGS_0	/* nothing to do */
-# define POPARGS_1	POPARGS_0 ldw -36(%sr0,%sp), %r26	ASM_LINE_SEP
-# define POPARGS_2	POPARGS_1 ldw -40(%sr0,%sp), %r25	ASM_LINE_SEP
-# define POPARGS_3	POPARGS_2 ldw -44(%sr0,%sp), %r24	ASM_LINE_SEP
-# define POPARGS_4	POPARGS_3 ldw -48(%sr0,%sp), %r23	ASM_LINE_SEP
-# define POPARGS_5	POPARGS_4 ldw -52(%sr0,%sp), %r22	ASM_LINE_SEP
-# define POPARGS_6	POPARGS_5 ldw -56(%sr0,%sp), %r21	ASM_LINE_SEP
+# define POPARGS_1	POPARGS_0 ldw -36(%sr0,%sp), %r26	ASM_LINE_SEP	\
+			.cfi_restore 26				ASM_LINE_SEP
+# define POPARGS_2	POPARGS_1 ldw -40(%sr0,%sp), %r25	ASM_LINE_SEP	\
+			.cfi_restore 25				ASM_LINE_SEP
+# define POPARGS_3	POPARGS_2 ldw -44(%sr0,%sp), %r24	ASM_LINE_SEP	\
+			.cfi_restore 24				ASM_LINE_SEP
+# define POPARGS_4	POPARGS_3 ldw -48(%sr0,%sp), %r23	ASM_LINE_SEP	\
+			.cfi_restore 23				ASM_LINE_SEP
+# define POPARGS_5	POPARGS_4 ldw -52(%sr0,%sp), %r22	ASM_LINE_SEP	\
+			.cfi_restore 22				ASM_LINE_SEP
+# define POPARGS_6	POPARGS_5 ldw -56(%sr0,%sp), %r21	ASM_LINE_SEP	\
+			.cfi_restore 21				ASM_LINE_SEP
 
 # ifdef IS_IN_libpthread
 #  ifdef PIC
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/procfs.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/hppa/sys/procfs.h	2011-09-04 14:18:44.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/procfs.h	2011-09-04 14:20:23.000000000 -0400
@@ -29,10 +29,8 @@
    GDB unless you know what you are doing.  */
 
 #include <features.h>
-#include <signal.h>
 #include <sys/time.h>
 #include <sys/types.h>
-#include <sys/ucontext.h>
 #include <sys/user.h>
 
 __BEGIN_DECLS
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sysdep.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/hppa/sysdep.h	2011-09-04 14:19:27.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sysdep.h	2011-09-04 14:20:23.000000000 -0400
@@ -22,7 +22,6 @@
 
 #include <asm/unistd.h>
 #include <sysdeps/generic/sysdep.h>
-#include <sys/syscall.h>
 
 /* In order to get __set_errno() definition in INLINE_SYSCALL.  */
 #ifndef __ASSEMBLER__
@@ -35,32 +34,28 @@
 #undef SYS_ify
 #define SYS_ify(syscall_name)	(__NR_##syscall_name)
 
+/* The vfork, fork, and clone syscalls clobber r19
+ * and r21. We list r21 as either clobbered or as an
+ * input to a 6-argument syscall. We must save and
+ * restore r19 in both PIC and non-PIC cases.
+ */ 
 /* WARNING: TREG must be a callee saves register so 
    that it doesn't have to be restored after a call 
    to another function */
-#ifdef PIC
-# define TREG %r3
-# define SAVE_PIC(SREG) copy %r19, SREG ASM_LINE_SEP
-# define LOAD_PIC(LREG) copy LREG, %r19 ASM_LINE_SEP
-/* Inline assembly defines */
-# define TREG_ASM "%r4" /* Cant clobber r3, it holds framemarker */
-# define SAVE_ASM_PIC	"       copy %%r19, %" TREG_ASM "\n"
-# define LOAD_ASM_PIC	"       copy %" TREG_ASM ", %%r19\n"
-# define CLOB_TREG	TREG_ASM ,
-# define PIC_REG_DEF	register unsigned long __r19 asm("r19");
-# define PIC_REG_USE	, "r" (__r19)
-#else
-# define TREG %r3
-# define SAVE_PIC(SREG) nop ASM_LINE_SEP
-# define LOAD_PIC(LREG) nop ASM_LINE_SEP
+#define TREG 4
+#define SAVE_PIC(SREG) \
+	copy %r19, SREG ASM_LINE_SEP	\
+	.cfi_register 19, SREG
+#define LOAD_PIC(LREG) \
+	copy LREG , %r19 ASM_LINE_SEP	\
+	.cfi_restore 19
 /* Inline assembly defines */
-# define TREG_ASM 
-# define SAVE_ASM_PIC	"nop \n"
-# define LOAD_ASM_PIC	"nop \n"
-# define CLOB_TREG
-# define PIC_REG_DEF
-# define PIC_REG_USE
-#endif
+#define TREG_ASM "%r4" /* Cant clobber r3, it holds framemarker */
+#define SAVE_ASM_PIC	"       copy %%r19, %" TREG_ASM "\n"
+#define LOAD_ASM_PIC	"       copy %" TREG_ASM ", %%r19\n"
+#define CLOB_TREG	TREG_ASM ,
+#define PIC_REG_DEF	register unsigned long __r19 asm("r19");
+#define PIC_REG_USE	, "r" (__r19)
 
 #ifdef __ASSEMBLER__
 
@@ -127,12 +122,14 @@
 	.align ALIGNARG(4)				ASM_LINE_SEP	\
 	.export C_SYMBOL_NAME(name)			ASM_LINE_SEP	\
 	.type	C_SYMBOL_NAME(name),@function		ASM_LINE_SEP	\
+	cfi_startproc					ASM_LINE_SEP	\
 	C_LABEL(name)					ASM_LINE_SEP	\
 	.PROC						ASM_LINE_SEP	\
 	.CALLINFO FRAME=64,CALLS,SAVE_RP,ENTRY_GR=3	ASM_LINE_SEP	\
 	.ENTRY						ASM_LINE_SEP	\
 	/* SAVE_RP says we do */			ASM_LINE_SEP	\
 	stw %rp, -20(%sr0,%sp)				ASM_LINE_SEP	\
+	.cfi_offset 2, -20				ASM_LINE_SEP	\
 	/*FIXME: Call mcount? (carefull with stack!) */
 
 /* Some syscall wrappers do not call other functions, and
@@ -142,18 +139,21 @@
 	.align ALIGNARG(4)				ASM_LINE_SEP	\
 	.export C_SYMBOL_NAME(name)			ASM_LINE_SEP	\
 	.type	C_SYMBOL_NAME(name),@function		ASM_LINE_SEP	\
+	cfi_startproc					ASM_LINE_SEP	\
 	C_LABEL(name)					ASM_LINE_SEP	\
 	.PROC						ASM_LINE_SEP	\
 	.CALLINFO FRAME=64,NO_CALLS,SAVE_RP,ENTRY_GR=3	ASM_LINE_SEP	\
 	.ENTRY						ASM_LINE_SEP	\
 	/* SAVE_RP says we do */			ASM_LINE_SEP	\
 	stw %rp, -20(%sr0,%sp)				ASM_LINE_SEP	\
+	.cfi_offset 2, -20				ASM_LINE_SEP	\
 	/*FIXME: Call mcount? (carefull with stack!) */
 
 #undef	END
 #define END(name)							\
   	.EXIT						ASM_LINE_SEP	\
 	.PROCEND					ASM_LINE_SEP	\
+	cfi_endproc					ASM_LINE_SEP	\
 .size	C_SYMBOL_NAME(name), .-C_SYMBOL_NAME(name)	ASM_LINE_SEP
 
 /* If compiled for profiling, call `mcount' at the start 
@@ -170,9 +170,7 @@
    which means
 	ENTRY(name)
 	DO_CALL(...)
-	nop
-	bv 0(2)
-	nop
+	bv,n 0(2)
 */
 
 #define	PSEUDO(name, syscall_name, args)			\
@@ -180,8 +178,7 @@
   /* If necc. load args from stack */		ASM_LINE_SEP	\
   DOARGS_##args					ASM_LINE_SEP	\
   DO_CALL (syscall_name, args)			ASM_LINE_SEP	\
-  UNDOARGS_##args				ASM_LINE_SEP	\
-  nop						ASM_LINE_SEP
+  UNDOARGS_##args				ASM_LINE_SEP
 
 #define ret \
   /* Return value set by ERRNO code */		ASM_LINE_SEP	\
@@ -196,8 +193,7 @@
   ENTRY_LEAF (name)				ASM_LINE_SEP	\
   DOARGS_##args					ASM_LINE_SEP	\
   DO_CALL_NOERRNO (syscall_name, args)		ASM_LINE_SEP	\
-  UNDOARGS_##args				ASM_LINE_SEP	\
-  nop						ASM_LINE_SEP
+  UNDOARGS_##args				ASM_LINE_SEP
 
 #define ret_NOERRNO ret
 
@@ -211,8 +207,7 @@
   ENTRY_LEAF (name)				ASM_LINE_SEP	\
   DOARGS_##args					ASM_LINE_SEP	\
   DO_CALL_ERRVAL (syscall_name, args)		ASM_LINE_SEP	\
-  UNDOARGS_##args				ASM_LINE_SEP	\
-  nop						ASM_LINE_SEP
+  UNDOARGS_##args				ASM_LINE_SEP
 
 #define ret_ERRVAL ret
 
@@ -290,8 +285,12 @@
 #define DO_CALL(syscall_name, args)				\
 	/* Create a frame */			ASM_LINE_SEP	\
 	stwm TREG, 64(%sp)			ASM_LINE_SEP	\
+	.cfi_offset TREG, 0			ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset 64		ASM_LINE_SEP	\
 	stw %sp, -4(%sp)			ASM_LINE_SEP	\
+	.cfi_offset 30, -4			ASM_LINE_SEP	\
 	stw %r19, -32(%sp)			ASM_LINE_SEP	\
+	.cfi_offset 19, -32			ASM_LINE_SEP	\
 	/* Save r19 */				ASM_LINE_SEP	\
 	SAVE_PIC(TREG)				ASM_LINE_SEP	\
 	/* Do syscall, delay loads # */		ASM_LINE_SEP	\
@@ -314,8 +313,10 @@
 L(pre_end):					ASM_LINE_SEP	\
 	/* Restore our frame, restoring TREG */	ASM_LINE_SEP	\
 	ldwm -64(%sp), TREG			ASM_LINE_SEP	\
+	.cfi_adjust_cfa_offset -64		ASM_LINE_SEP	\
 	/* Restore return pointer */		ASM_LINE_SEP	\
-	ldw -20(%sp),%rp			ASM_LINE_SEP
+	ldw -20(%sp),%rp			ASM_LINE_SEP	\
+	.cfi_restore 2				ASM_LINE_SEP
 
 /* We do nothing with the return, except hand it back to someone else */
 #undef  DO_CALL_NOERRNO

[-- Attachment #3: ports-2011-09-17.diff --]
[-- Type: application/octet-stream, Size: 1517 bytes --]

Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h
===================================================================
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h	2011-09-05 00:09:53.000000000 -0400
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h	2011-09-17 23:07:14.000000000 -0400
@@ -288,18 +288,20 @@
   __lll_robust_timedlock (&(futex), abstime, id, private)
 
 #define __lll_unlock(futex, private) \
-  (void)					\
-  ({ int val = atomic_exchange_rel (futex, 0);  \
-     if (__builtin_expect (val > 1, 0))         \
-       lll_futex_wake (futex, 1, private);      \
+  (void)						\
+  ({ int *__futex = (futex);				\
+     int val = atomic_exchange_rel (__futex, 0);	\
+     if (__builtin_expect (val > 1, 0))			\
+       lll_futex_wake (__futex, 1, private);		\
   })
 #define lll_unlock(futex, private) __lll_unlock(&(futex), private)
 
 #define  __lll_robust_unlock(futex,private) \
-  (void)                                               \
-    ({ int val = atomic_exchange_rel (futex, 0);       \
-       if (__builtin_expect (val & FUTEX_WAITERS, 0))  \
-         lll_futex_wake (futex, 1, private);           \
+  (void)						\
+    ({ int *__futex = (futex);				\
+       int val = atomic_exchange_rel (__futex, 0);	\
+       if (__builtin_expect (val & FUTEX_WAITERS, 0))	\
+         lll_futex_wake (__futex, 1, private);		\
     })
 #define lll_robust_unlock(futex, private) \
   __lll_robust_unlock(&(futex), private)

[-- Attachment #4: ports-2011-10-30.diff --]
[-- Type: application/octet-stream, Size: 17124 bytes --]

Index: eglibc-2.13/ports/ChangeLog.hppa
===================================================================
--- eglibc-2.13.orig/ports/ChangeLog.hppa	2011-09-24 18:40:01.000000000 -0400
+++ eglibc-2.13/ports/ChangeLog.hppa	2011-10-30 11:43:20.000000000 -0400
@@ -3,6 +3,19 @@
 	* sysdeps/hppa/dl-machine.h: Update copyright year.
 	(ELF_MACHINE_BEFORE_RTLD_RELOC): Call _dl_fptr_init.
 
+2010-08-06  Guy Martin <gmsoft@tuxicoman.be>
+
+	* ports/sysdeps/unix/sysv/linux/hppa/sys/epoll.h:
+	Fix EPOLL_CLOEXEC and EPOLL_NONBLOCK to match kernel definition.
+	* ports/sysdeps/unix/sysv/linux/hppa/sys/eventfd.h:
+	Fix EFD_CLOEXEC and EFD_NONBLOCK to match kernel definition.
+	* ports/sysdeps/unix/sysv/linux/hppa/sys/inotify.h:
+	Fix IN_CLOEXEC and IN_NONBLOCK to match kernel definition.
+	* ports/sysdeps/unix/sysv/linux/hppa/sys/signalfd.h:
+	Fix SFD_CLOEXEC and SFD_NONBLOCK to match kernel definition.
+	* ports/sysdeps/unix/sysv/linux/hppa/sys/timerfd.h:
+	Fix TFD_CLOEXEC and TFD_NONBLOCK to match kernel definition.
+
 2010-06-24  Carlos O'Donell  <carlos@codesourcery.com>
 
 	* sysdeps/unix/sysv/linux/hppa/nptl/pt-vfork.S: Only create stack 
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/epoll.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/epoll.h	2011-10-30 11:44:30.000000000 -0400
@@ -0,0 +1,144 @@
+/* Copyright (C) 2002-2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_SYS_EPOLL_H
+#define	_SYS_EPOLL_H	1
+
+#include <stdint.h>
+#include <sys/types.h>
+
+/* Get __sigset_t.  */
+#include <bits/sigset.h>
+
+#ifndef __sigset_t_defined
+# define __sigset_t_defined
+typedef __sigset_t sigset_t;
+#endif
+
+
+/* Flags to be passed to epoll_create1.  */
+enum
+  {
+    EPOLL_CLOEXEC = 010000000,
+#define EPOLL_CLOEXEC EPOLL_CLOEXEC
+    EPOLL_NONBLOCK = 00200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define EPOLL_NONBLOCK EPOLL_NONBLOCK
+  };
+
+
+enum EPOLL_EVENTS
+  {
+    EPOLLIN = 0x001,
+#define EPOLLIN EPOLLIN
+    EPOLLPRI = 0x002,
+#define EPOLLPRI EPOLLPRI
+    EPOLLOUT = 0x004,
+#define EPOLLOUT EPOLLOUT
+    EPOLLRDNORM = 0x040,
+#define EPOLLRDNORM EPOLLRDNORM
+    EPOLLRDBAND = 0x080,
+#define EPOLLRDBAND EPOLLRDBAND
+    EPOLLWRNORM = 0x100,
+#define EPOLLWRNORM EPOLLWRNORM
+    EPOLLWRBAND = 0x200,
+#define EPOLLWRBAND EPOLLWRBAND
+    EPOLLMSG = 0x400,
+#define EPOLLMSG EPOLLMSG
+    EPOLLERR = 0x008,
+#define EPOLLERR EPOLLERR
+    EPOLLHUP = 0x010,
+#define EPOLLHUP EPOLLHUP
+    EPOLLRDHUP = 0x2000,
+#define EPOLLRDHUP EPOLLRDHUP
+    EPOLLONESHOT = (1 << 30),
+#define EPOLLONESHOT EPOLLONESHOT
+    EPOLLET = (1 << 31)
+#define EPOLLET EPOLLET
+  };
+
+
+/* Valid opcodes ( "op" parameter ) to issue to epoll_ctl().  */
+#define EPOLL_CTL_ADD 1	/* Add a file descriptor to the interface.  */
+#define EPOLL_CTL_DEL 2	/* Remove a file descriptor from the interface.  */
+#define EPOLL_CTL_MOD 3	/* Change file descriptor epoll_event structure.  */
+
+
+typedef union epoll_data
+{
+  void *ptr;
+  int fd;
+  uint32_t u32;
+  uint64_t u64;
+} epoll_data_t;
+
+struct epoll_event
+{
+  uint32_t events;	/* Epoll events */
+  epoll_data_t data;	/* User data variable */
+};
+
+
+__BEGIN_DECLS
+
+/* Creates an epoll instance.  Returns an fd for the new instance.
+   The "size" parameter is a hint specifying the number of file
+   descriptors to be associated with the new instance.  The fd
+   returned by epoll_create() should be closed with close().  */
+extern int epoll_create (int __size) __THROW;
+
+/* Same as epoll_create but with an FLAGS parameter.  The unused SIZE
+   parameter has been dropped.  */
+extern int epoll_create1 (int __flags) __THROW;
+
+
+/* Manipulate an epoll instance "epfd". Returns 0 in case of success,
+   -1 in case of error ( the "errno" variable will contain the
+   specific error code ) The "op" parameter is one of the EPOLL_CTL_*
+   constants defined above. The "fd" parameter is the target of the
+   operation. The "event" parameter describes which events the caller
+   is interested in and any associated user data.  */
+extern int epoll_ctl (int __epfd, int __op, int __fd,
+		      struct epoll_event *__event) __THROW;
+
+
+/* Wait for events on an epoll instance "epfd". Returns the number of
+   triggered events returned in "events" buffer. Or -1 in case of
+   error with the "errno" variable set to the specific error code. The
+   "events" parameter is a buffer that will contain triggered
+   events. The "maxevents" is the maximum number of events to be
+   returned ( usually size of "events" ). The "timeout" parameter
+   specifies the maximum wait time in milliseconds (-1 == infinite).
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int epoll_wait (int __epfd, struct epoll_event *__events,
+		       int __maxevents, int __timeout);
+
+
+/* Same as epoll_wait, but the thread's signal mask is temporarily
+   and atomically replaced with the one provided as parameter.
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int epoll_pwait (int __epfd, struct epoll_event *__events,
+			int __maxevents, int __timeout,
+			__const __sigset_t *__ss);
+
+__END_DECLS
+
+#endif /* sys/epoll.h */
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/eventfd.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/eventfd.h	2011-10-30 11:44:30.000000000 -0400
@@ -0,0 +1,54 @@
+/* Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_SYS_EVENTFD_H
+#define	_SYS_EVENTFD_H	1
+
+#include <stdint.h>
+
+
+/* Type for event counter.  */
+typedef uint64_t eventfd_t;
+
+/* Flags for signalfd.  */
+enum
+  {
+    EFD_SEMAPHORE = 1,
+#define EFD_SEMAPHORE EFD_SEMAPHORE
+    EFD_CLOEXEC = 010000000,
+#define EFD_CLOEXEC EFD_CLOEXEC
+    EFD_NONBLOCK = 00200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define EFD_NONBLOCK EFD_NONBLOCK
+  };
+
+
+__BEGIN_DECLS
+
+/* Return file descriptor for generic event channel.  Set initial
+   value to COUNT.  */
+extern int eventfd (int __count, int __flags) __THROW;
+
+/* Read event counter and possibly wait for events.  */
+extern int eventfd_read (int __fd, eventfd_t *__value);
+
+/* Increment event counter.  */
+extern int eventfd_write (int __fd, eventfd_t __value);
+
+__END_DECLS
+
+#endif /* sys/eventfd.h */
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/inotify.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/inotify.h	2011-10-30 11:44:30.000000000 -0400
@@ -0,0 +1,105 @@
+/* Copyright (C) 2005, 2006, 2008, 2009 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_SYS_INOTIFY_H
+#define	_SYS_INOTIFY_H	1
+
+#include <stdint.h>
+
+
+/* Flags for the parameter of inotify_init1.  */
+enum
+  {
+    IN_CLOEXEC = 010000000,
+#define IN_CLOEXEC IN_CLOEXEC
+    IN_NONBLOCK = 000200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define IN_NONBLOCK IN_NONBLOCK
+  };
+
+
+/* Structure describing an inotify event.  */
+struct inotify_event
+{
+  int wd;		/* Watch descriptor.  */
+  uint32_t mask;	/* Watch mask.  */
+  uint32_t cookie;	/* Cookie to synchronize two events.  */
+  uint32_t len;		/* Length (including NULs) of name.  */
+  char name __flexarr;	/* Name.  */
+};
+
+
+/* Supported events suitable for MASK parameter of INOTIFY_ADD_WATCH.  */
+#define IN_ACCESS	 0x00000001	/* File was accessed.  */
+#define IN_MODIFY	 0x00000002	/* File was modified.  */
+#define IN_ATTRIB	 0x00000004	/* Metadata changed.  */
+#define IN_CLOSE_WRITE	 0x00000008	/* Writtable file was closed.  */
+#define IN_CLOSE_NOWRITE 0x00000010	/* Unwrittable file closed.  */
+#define IN_CLOSE	 (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE) /* Close.  */
+#define IN_OPEN		 0x00000020	/* File was opened.  */
+#define IN_MOVED_FROM	 0x00000040	/* File was moved from X.  */
+#define IN_MOVED_TO      0x00000080	/* File was moved to Y.  */
+#define IN_MOVE		 (IN_MOVED_FROM | IN_MOVED_TO) /* Moves.  */
+#define IN_CREATE	 0x00000100	/* Subfile was created.  */
+#define IN_DELETE	 0x00000200	/* Subfile was deleted.  */
+#define IN_DELETE_SELF	 0x00000400	/* Self was deleted.  */
+#define IN_MOVE_SELF	 0x00000800	/* Self was moved.  */
+
+/* Events sent by the kernel.  */
+#define IN_UNMOUNT	 0x00002000	/* Backing fs was unmounted.  */
+#define IN_Q_OVERFLOW	 0x00004000	/* Event queued overflowed.  */
+#define IN_IGNORED	 0x00008000	/* File was ignored.  */
+
+/* Helper events.  */
+#define IN_CLOSE	 (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)	/* Close.  */
+#define IN_MOVE		 (IN_MOVED_FROM | IN_MOVED_TO)		/* Moves.  */
+
+/* Special flags.  */
+#define IN_ONLYDIR	 0x01000000	/* Only watch the path if it is a
+					   directory.  */
+#define IN_DONT_FOLLOW	 0x02000000	/* Do not follow a sym link.  */
+#define IN_MASK_ADD	 0x20000000	/* Add to the mask of an already
+					   existing watch.  */
+#define IN_ISDIR	 0x40000000	/* Event occurred against dir.  */
+#define IN_ONESHOT	 0x80000000	/* Only send event once.  */
+
+/* All events which a program can wait on.  */
+#define IN_ALL_EVENTS	 (IN_ACCESS | IN_MODIFY | IN_ATTRIB | IN_CLOSE_WRITE  \
+			  | IN_CLOSE_NOWRITE | IN_OPEN | IN_MOVED_FROM	      \
+			  | IN_MOVED_TO | IN_CREATE | IN_DELETE		      \
+			  | IN_DELETE_SELF | IN_MOVE_SELF)
+
+
+__BEGIN_DECLS
+
+/* Create and initialize inotify instance.  */
+extern int inotify_init (void) __THROW;
+
+/* Create and initialize inotify instance.  */
+extern int inotify_init1 (int __flags) __THROW;
+
+/* Add watch of object NAME to inotify instance FD.  Notify about
+   events specified by MASK.  */
+extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask)
+  __THROW;
+
+/* Remove the watch specified by WD from the inotify instance FD.  */
+extern int inotify_rm_watch (int __fd, int __wd) __THROW;
+
+__END_DECLS
+
+#endif /* sys/inotify.h */
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/signalfd.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/signalfd.h	2011-10-30 11:44:30.000000000 -0400
@@ -0,0 +1,66 @@
+/* Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_SYS_SIGNALFD_H
+#define	_SYS_SIGNALFD_H	1
+
+#define __need_sigset_t
+#include <signal.h>
+#include <stdint.h>
+
+
+struct signalfd_siginfo
+{
+  uint32_t ssi_signo;
+  int32_t ssi_errno;
+  int32_t ssi_code;
+  uint32_t ssi_pid;
+  uint32_t ssi_uid;
+  int32_t ssi_fd;
+  uint32_t ssi_tid;
+  uint32_t ssi_band;
+  uint32_t ssi_overrun;
+  uint32_t ssi_trapno;
+  int32_t ssi_status;
+  int32_t ssi_int;
+  uint64_t ssi_ptr;
+  uint64_t ssi_utime;
+  uint64_t ssi_stime;
+  uint64_t ssi_addr;
+  uint8_t __pad[48];
+};
+
+/* Flags for signalfd.  */
+enum
+  {
+    SFD_CLOEXEC = 010000000,
+#define SFD_CLOEXEC SFD_CLOEXEC
+    SFD_NONBLOCK = 00200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define SFD_NONBLOCK SFD_NONBLOCK
+  };
+
+__BEGIN_DECLS
+
+/* Request notification for delivery of signals in MASK to be
+   performed using descriptor FD.*/
+extern int signalfd (int __fd, const sigset_t *__mask, int __flags)
+  __THROW __nonnull ((2));
+
+__END_DECLS
+
+#endif /* sys/signalfd.h */
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/timerfd.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/hppa/sys/timerfd.h	2011-10-30 11:44:30.000000000 -0400
@@ -0,0 +1,60 @@
+/* Copyright (C) 2008 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_SYS_TIMERFD_H
+#define	_SYS_TIMERFD_H	1
+
+#include <time.h>
+
+
+/* Bits to be set in the FLAGS parameter of `timerfd_create'.  */
+enum
+  {
+    TFD_CLOEXEC = 010000000,
+#define TFD_CLOEXEC TFD_CLOEXEC
+    TFD_NONBLOCK = 000200004 /* HPUX has separate NDELAY & NONBLOCK */
+#define TFD_NONBLOCK TFD_NONBLOCK
+  };
+
+
+/* Bits to be set in the FLAGS parameter of `timerfd_settime'.  */
+enum
+  {
+    TFD_TIMER_ABSTIME = 1 << 0
+#define TFD_TIMER_ABSTIME TFD_TIMER_ABSTIME
+  };
+
+
+__BEGIN_DECLS
+
+/* Return file descriptor for new interval timer source.  */
+extern int timerfd_create (clockid_t __clock_id, int __flags) __THROW;
+
+/* Set next expiration time of interval timer source UFD to UTMR.  If
+   FLAGS has the TFD_TIMER_ABSTIME flag set the timeout value is
+   absolute.  Optionally return the old expiration time in OTMR.  */
+extern int timerfd_settime (int __ufd, int __flags,
+			    __const struct itimerspec *__utmr,
+			    struct itimerspec *__otmr) __THROW;
+
+/* Return the next expiration time of UFD.  */
+extern int timerfd_gettime (int __ufd, struct itimerspec *__otmr) __THROW;
+
+__END_DECLS
+
+#endif /* sys/timerfd.h */

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31  1:36                         ` John David Anglin
  2011-10-31  9:41                           ` Domenico Andreoli
@ 2011-11-01  2:15                           ` Carlos O'Donell
  2011-11-01  9:19                             ` Domenico Andreoli
  1 sibling, 1 reply; 38+ messages in thread
From: Carlos O'Donell @ 2011-11-01  2:15 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On 10/30/2011 9:36 PM, John David Anglin wrote:
> I've been wondering how much is left to install to glibc head?

I've pushed out almost all of glibc-ports into upstream.

There are probably a half-dozen patches against glibc proper for which I'm writing up submissions and making sure I don't impact x86 fast path.

Submitting patches to core glibc isn't like any other project :-)

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-10-31 23:26                             ` John David Anglin
@ 2011-11-01  9:15                               ` Domenico Andreoli
  0 siblings, 0 replies; 38+ messages in thread
From: Domenico Andreoli @ 2011-11-01  9:15 UTC (permalink / raw)
  To: John David Anglin
  Cc: Carlos O'Donell, Rolf Eike Beer, linux-parisc, debian-hppa

On Mon, Oct 31, 2011 at 07:26:56PM -0400, John David Anglin wrote:
> On 31-Oct-11, at 5:41 AM, Domenico Andreoli wrote:
> 
> >I would like to redo the exercise on my j5600, are you building Debian
> >packages? Could you please share the sources? Thank you.
> 
> Attached are the hppa libc6 patches that I'm using.  The
> local-stack-grows-up.diff patch needs
> to be removed first, then the patches applied in order of date using
> quilt.
> 
> The last change resolves the udev bug.
> 
> I will send you offline the eglibc_2.13-10.dsc  and the
> eglibc_2.13-10.diff.gz.  The
> eglibc_2.13.orig.tar.gz file should still be available.

I'll give it a ride as soon as I can, thank you.

cheers,
Domenico

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-11-01  2:15                           ` Carlos O'Donell
@ 2011-11-01  9:19                             ` Domenico Andreoli
  2011-11-01 19:56                               ` John David Anglin
  0 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2011-11-01  9:19 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: John David Anglin, Rolf Eike Beer, linux-parisc

On Mon, Oct 31, 2011 at 10:15:06PM -0400, Carlos O'Donell wrote:
> On 10/30/2011 9:36 PM, John David Anglin wrote:
> > I've been wondering how much is left to install to glibc head?
> 
> I've pushed out almost all of glibc-ports into upstream.
> 
> There are probably a half-dozen patches against glibc proper for which I'm writing up submissions and making sure I don't impact x86 fast path.
> 
> Submitting patches to core glibc isn't like any other project :-)

glibc or eglibc?

cheers,
Domenico

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] parisc: futex: Use same lock set as lws calls
  2011-11-01  9:19                             ` Domenico Andreoli
@ 2011-11-01 19:56                               ` John David Anglin
  0 siblings, 0 replies; 38+ messages in thread
From: John David Anglin @ 2011-11-01 19:56 UTC (permalink / raw)
  To: Carlos O'Donell, Rolf Eike Beer, linux-parisc

On 11/1/2011 5:19 AM, Domenico Andreoli wrote:
> On Mon, Oct 31, 2011 at 10:15:06PM -0400, Carlos O'Donell wrote:
>> >  On 10/30/2011 9:36 PM, John David Anglin wrote:
>>> >  >  I've been wondering how much is left to install to glibc head?
>> >  
>> >  I've pushed out almost all of glibc-ports into upstream.
>> >  
>> >  There are probably a half-dozen patches against glibc proper for which I'm writing up submissions and making sure I don't impact x86 fast path.
>> >  
>> >  Submitting patches to core glibc isn't like any other project:-)
> glibc or eglibc?
Many of the debian packages that I have been building seem for cell phones,
so I understand the confusion 8-)

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2011-11-01 19:56 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-09 20:40 [PATCH] parisc: futex: Use same lock set as lws calls John David Anglin
2011-10-10 14:30 ` Rolf Eike Beer
2011-10-10 20:27   ` John David Anglin
2011-10-10 20:30     ` James Bottomley
2011-10-17 15:23 ` Domenico Andreoli
2011-10-17 15:47   ` Carlos O'Donell
2011-10-17 18:10     ` John David Anglin
2011-10-17 20:55       ` Carlos O'Donell
2011-10-17 21:09         ` John David Anglin
2011-10-17 21:57           ` Domenico Andreoli
2011-10-17 22:28             ` John David Anglin
2011-10-18  9:31               ` Domenico Andreoli
2011-10-18  9:33               ` Domenico Andreoli
2011-10-18 14:20                 ` John David Anglin
2011-10-18  3:01           ` Carlos O'Donell
2011-10-18  3:21             ` Carlos O'Donell
2011-10-18 21:22               ` Carlos O'Donell
2011-10-20 15:35           ` Carlos O'Donell
2011-10-20 17:57             ` Matt Turner
2011-10-20 18:11               ` Carlos O'Donell
2011-10-20 18:16                 ` Matt Turner
2011-10-20  1:47       ` John David Anglin
2011-10-21 14:49         ` Carlos O'Donell
2011-10-21 17:42           ` John David Anglin
2011-10-21 18:11             ` John David Anglin
2011-10-21 18:15               ` Carlos O'Donell
2011-10-30 15:04                 ` John David Anglin
2011-10-30 15:31                   ` Rolf Eike Beer
2011-10-30 16:13                     ` John David Anglin
2011-10-31  0:21                       ` Carlos O'Donell
2011-10-31  1:36                         ` John David Anglin
2011-10-31  9:41                           ` Domenico Andreoli
2011-10-31 12:28                             ` John David Anglin
2011-10-31 23:26                             ` John David Anglin
2011-11-01  9:15                               ` Domenico Andreoli
2011-11-01  2:15                           ` Carlos O'Donell
2011-11-01  9:19                             ` Domenico Andreoli
2011-11-01 19:56                               ` John David Anglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).