[parisc-linux] new glibc dpatch

[parisc-linux] new glibc dpatch

[Matthew Wilcox]

due to a few people hassling me, i've created a new hppa patch for glibc.
it incorporates a couple of changes Carlos posted to the list and adds a
couple of diffs of my own.  i've sent it to BenC for the 2.2.4-4 release
of glibc, which he assures me is imminent.

You can find it at
ftp://puffin.external.hp.com/pub/parisc/src/glibc22-hppa.dpatch

have fun.  it's still building on paer.d.o, but i would expect it to
fail to build in the same place as before.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] new glibc dpatch

[Carlos O'Donell Jr.]

> 
> due to a few people hassling me, i've created a new hppa patch for glibc.
> it incorporates a couple of changes Carlos posted to the list and adds a
> couple of diffs of my own.  i've sent it to BenC for the 2.2.4-4 release
> of glibc, which he assures me is imminent.
> 

That's my name!

> You can find it at
> ftp://puffin.external.hp.com/pub/parisc/src/glibc22-hppa.dpatch
> 
> have fun.  it's still building on paer.d.o, but i would expect it to
> fail to build in the same place as before.

Looking through the patch changes and comparing to mine.
(The build has begun)

Just a comment about your changes to ./sysdeps/ia64/dl-fptr.c

=====
--- glibc22-hppa.dpatch	Tue Oct 16 20:52:02 2001
+++ glibc22-hppa.dpatch.mw	Tue Oct 16 21:05:27 2001
@@ -1135,7 +1135,7 @@
      unsigned int npages;		/* # of pages to allocate */
  #ifdef _LIBC_REENTRANT
 -    volatile int lock;
-+    __atomic_lock_t lock;
++    static __atomic_lock_t lock = __ATOMIC_LOCK_INIT;
      sigset_t full_sigset;
  #endif
      /* the next to members MUST be consecutive! */
=====

Should the lock be static and initialized? Comment?

c.

Re: [parisc-linux] new glibc dpatch

[Matthew Wilcox]

On Wed, Oct 17, 2001 at 12:14:53AM -0400, Carlos O'Donell Jr. wrote:
> Just a comment about your changes to ./sysdeps/ia64/dl-fptr.c
> 
> =====
> --- glibc22-hppa.dpatch	Tue Oct 16 20:52:02 2001
> +++ glibc22-hppa.dpatch.mw	Tue Oct 16 21:05:27 2001
> @@ -1135,7 +1135,7 @@
>       unsigned int npages;		/* # of pages to allocate */
>   #ifdef _LIBC_REENTRANT
>  -    volatile int lock;
> -+    __atomic_lock_t lock;
> ++    static __atomic_lock_t lock = __ATOMIC_LOCK_INIT;
>       sigset_t full_sigset;
>   #endif
>       /* the next to members MUST be consecutive! */
> =====

I'm not sure what meaning static would have in this context.  It doesn't
have to be initialised because every arch other than PA defines an
unlocked lock to be 0.  If it gets initialised, it gets put in .data
(instead of .bss), even if you're initialising it to 0.  Stupid, I know.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] new glibc dpatch

[Carlos O'Donell Jr.]

> > 
> > =====
> > --- glibc22-hppa.dpatch	Tue Oct 16 20:52:02 2001
> > +++ glibc22-hppa.dpatch.mw	Tue Oct 16 21:05:27 2001
> > @@ -1135,7 +1135,7 @@
> >       unsigned int npages;		/* # of pages to allocate */
> >   #ifdef _LIBC_REENTRANT
> >  -    volatile int lock;
> > -+    __atomic_lock_t lock;
> > ++    static __atomic_lock_t lock = __ATOMIC_LOCK_INIT;
> >       sigset_t full_sigset;
> >   #endif
> >       /* the next to members MUST be consecutive! */
> > =====
> 
> I'm not sure what meaning static would have in this context.  It doesn't
> have to be initialised because every arch other than PA defines an
> unlocked lock to be 0.  If it gets initialised, it gets put in .data
> (instead of .bss), even if you're initialising it to 0.  Stupid, I know.
>

My bad. The entire struct is defined as static.
The static identifier was to prevent external modifcation of the value.
However since it's encased in a "static struct local" it's not an issue.

True. Any initialized value needs to be shipped into .data, and we
begin to see some ugly .data bloat (even if the user is just specifying
zero anyway...)


I think I'm going to get some sleep now ... to many "my bad" in one 
day ^__^;;;

c.