Re: [parisc-linux] testandset

Re: [parisc-linux] testandset

[Carlos O'Donell Jr.]

> 
> because we're removing the testandset macro, replacing it with try_lock.
> 

Noted.

> > e) Packed it all back up as tar.bz2 (./debian rules seems to call for this)
> 
> No, definitely not, I don't know why you think you need to do that.
> 

Thus my belief that I'm using the dpkg-dev tools wrong.
I read the docs late at night... maybe I didn't read them at all,
maybe I just dreamt that I did? ;)

> dpkg-source -x *dsc
> cd glibc-*
> frob 0lists & hppa.dpatch as above
> put a copy of the kernel includes in /usr/src/linux/include rather than setting
> LINUX_SOURCE
> dpkg-buildpackage -B -a -rfakeroot

I will give it another go (I've done a few compiles already).

My 712/60 is painfully slow :} 
Any recommendations for a faster machine?

We're almost to the point of setting up (Paul is looking at it)
pmake to build glibc. Hey, we've got a cluster for a reason.

Has anyone on this list used fai with hppa on this list?
http://www.informatik.uni-koeln.de/fai/.
(Hrm.. I'll post to beowulf@beowulf.org)

c.

[parisc-linux] testandset

[Carlos O'Donell Jr.]

I remember Wilcox saying:

"
Because we can't implement testandset atomically & efficiently on hppa.
The places which use testandset actually just need trylock.
"

Was the old testandset changed to try_lock in pt-machine.h for
hppa?

I see that they are the same asm statement (i.e. just an ldcw).

pt-machine.h:old:
testandset (int *spinlock)
{
  int ret;

  __asm__ __volatile__(
       "ldcw 0(%2),%0"
       : "=r"(ret), "=m"(*spinlock)
       : "r"(spinlock));

  return ret == 0;
}

pt-machine.h:new:
try_lock(__atomic_lock_t *spinlock)
{
  int ret;

  __asm__ __volatile__(
       "ldcw 0(%2),%0"
       : "=r"(ret), "=m"(*spinlock)
       : "r"(spinlock));

  return ret == 0;
}

Same...

I'm sitting scratching my head becaues the ./sysdeps/hppa/dl-fptr.c
is peppered with testandset, which used to be in pt-machine.h,
but is now called try_lock within pt-machine.h

Which is my current reason that glibc-2.2.4 failes to build
Because dl-fptr.c makes use of testandset, which is no longer 
in pt-machine.h.

Do I have something backwards?
I'm starting to think that I should take a look at dpkg-buildpackage,
and if I'm using it all properly.

---

Matthew,

Since I can't quite get to the point where zic barfs while 
walking the timezones... I'm not much help ;)


c.

Re: [parisc-linux] testandset

[Matthew Wilcox]

On Fri, Sep 21, 2001 at 11:37:00AM -0400, Carlos O'Donell Jr. wrote:
> I'm sitting scratching my head becaues the ./sysdeps/hppa/dl-fptr.c
> is peppered with testandset, which used to be in pt-machine.h,
> but is now called try_lock within pt-machine.h

um, the hppa.dpatch definitely does patch this.  perhaps you were
overzealous with trimming the ia64 part of the patch?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] testandset

[Carlos O'Donell Jr.]

> > I'm sitting scratching my head becaues the ./sysdeps/hppa/dl-fptr.c
> > is peppered with testandset, which used to be in pt-machine.h,
> > but is now called try_lock within pt-machine.h
> 
> um, the hppa.dpatch definitely does patch this.  perhaps you were
> overzealous with trimming the ia64 part of the patch?
>

Hrm. Maybe. I remember cutting out only the ia64 part.
I'll zip through the patch again.

<carlos goes to check>

Hrm. Time to start vaping source trees.
The only diff from the patches is the ia64 stuff. Which I've
fixed to use try_lock, so it's not necc anymore.

I am now sure that I've been using the dpkg tools incorrectly.
I will follow the steps you've outlined and do some more reading.

Thanks for the help M.

Cheers,
c. 

[parisc-linux] testandset

[Carlos O'Donell Jr.]

parisc,

Trying to build glibc-2.2.4 on my 712/60

The build eventually halts because of the undefined "testandset"
---
/root/glibc_build/glibc-2.2.4/hppa-linux/obj/elf/ld.so.1: undefined reference to `testandset'
collect2: ld returned 1 exit status
make[4]: *** [/root/glibc_build/glibc-2.2.4/hppa-linux/obj/libio/tst_swscanf] Error 1
---

I've read all the docs for dpkg-dev, and yet the glibc debian stuff behaves
slightly different.

a) Unpack glibc 2.2.4, linux-threads, db1-add-on.
b) Patch to 2.2.4-1
c) Needed to comment hppa stuff back into 0list
d) Removed dl-fptr stuff from the hppa.dpatch (for now)
	= Added morally equivalent changes to locking macro in ./sysdeps/ia64/dl-fptr.c
	= testandset->try_lock
	= Though I'm scratching my head at hppa/dl-fptr.c?
	= Why is the ia64 stuff being touched anyway?
	
e) Packed it all back up as tar.bz2 (./debian rules seems to call for this)
f) Placed the tar.bz2's in the glibc-2.2.4 directory (so that they can be unpacked)
f) export LINUX_SOURCE=/usr/src/linux (no kernel-headers pakcage yet)
g) dpkg-buildpackage -uc -b -d (from within XXX/glibc-2.2.4)

glibc is almost as magical as the woman in the chair beside me watching 
me type this email.

Debian has a ./rules section ... women don't :}

Any thoughts hackers?
Would you like the full dpkg-buildpackage log?

c.

Re: [parisc-linux] testandset

[Matthew Wilcox]

On Thu, Sep 20, 2001 at 09:12:31PM -0400, Carlos O'Donell Jr. wrote:
> I've read all the docs for dpkg-dev, and yet the glibc debian stuff behaves
> slightly different.
> 
> a) Unpack glibc 2.2.4, linux-threads, db1-add-on.
> b) Patch to 2.2.4-1
> c) Needed to comment hppa stuff back into 0list
> d) Removed dl-fptr stuff from the hppa.dpatch (for now)
> 	= Added morally equivalent changes to locking macro in ./sysdeps/ia64/dl-fptr.c
> 	= testandset->try_lock
> 	= Though I'm scratching my head at hppa/dl-fptr.c?
> 	= Why is the ia64 stuff being touched anyway?

because we're removing the testandset macro, replacing it with try_lock.

> e) Packed it all back up as tar.bz2 (./debian rules seems to call for this)

No, definitely not, I don't know why you think you need to do that.

> f) Placed the tar.bz2's in the glibc-2.2.4 directory (so that they can be unpacked)
> f) export LINUX_SOURCE=/usr/src/linux (no kernel-headers pakcage yet)
> g) dpkg-buildpackage -uc -b -d (from within XXX/glibc-2.2.4)

Here's what you ned to do:

dpkg-source -x *dsc
cd glibc-*
frob 0lists & hppa.dpatch as above
put a copy of the kernel includes in /usr/src/linux/include rather than setting
LINUX_SOURCE
dpkg-buildpackage -B -a -rfakeroot

-- 
Revolutions do not require corporate support.