[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[John David Anglin]

> Do you know of any other ABI breaks that could be coordinated with
> this transition?

No.  The last break was GCC 4.1.0 where the calling convention
for passing complex values was corrected.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Roland McGrath]

> I did a couple of tests and I verified that I have no words to spare.
> Adding an extra "int __pad" forces the structure to grow by 8 bytes
> due to the "long long" alignment requirements.

Just reorder the fields so that the 32-bit fields are all in groups of 2 or 4.
All that should matter is that the padding word is one of the first four so
you can detect the old initializer data, and that __mutex is the 6th
member so the PTHREAD_COND_INITIALIZER text works out to be warning-free.
In fact, that doesn't really matter since the initializer contents are all
zero regardless of spelling.  If need be, you can add a new first union
member not called __data, with a layout that makes PTHREAD_COND_INITIALIZER
happy. 
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Roland McGrath]

> Unfortunatly, due to alignment the NPTL pthread_cond_t grows larger
> than the Linuxthreads version when I add the padding. This is the only
> structure the grows larger in size than before. Is there any way I can
> avoid adding the padding?

It looks to me like you have one word to spare.  That's all you really
need.  That word will only ever be 1 from old PTHREAD_COND_INITIALIZER.
Checking all three padding words is really just paranoia trying to
distinguish clobbered structs from old initialized data.


Thanks,
Roland
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Roland McGrath]

> In the new structure we have shifted everything up because __lock is
> now an integer, instead of a _pthread_fastlock with a 4 word lock
> structure. Should I add padding after "__lock" e.g. int pad[3]?

Yes, you must dedicate those words to compatibility only.

> In an old executable the following static initializers:
> PTHREAD_MUTEX_INITIALIZER, PTHREAD_COND_INTIALIZER,
> PTHREAD_RWLOCK_INITIALIZER will setup the __spinlock structure to
> {1,1,1,1} e.g. unlocked in our Linuxthreads implementation.
> 
> To be clear are you suggesting I write compat wrappers for the
> pthread_mutex_*, pthread_cond_*, and pthread_rwlock_* functions to
> detect old style initialized locks, and reinitialize the lock word?

Yes.  The only ABIs affected are all functions taking pthread_mutex_t,
pthread_cond_t, or pthread_rwlock_t pointer arguments--except for
pthread_*_init, which are not affected because their only ABI contract is
the minimum size and alignment of available space at the pointer passed,
which hasn't gotten smaller.

Add sysdeps/unix/sysv/linux/hppa/nptl/Versions, with:

libc {
  GLIBC_2.6 {
    pthread_mutex_lock;
    ...all the affected symbols...
  }
}
libpthread {
  GLIBC_2.6 {
    pthread_mutex_lock;
    ...all the affected symbols...
  }
}

This is enough for the real functions all to get defined in the GLIBC_2.6
version set for ones that don't already have compatibility functions.  Some
pthread_cond functions already have compatibility functions for GLIBC_2.0,
and the way this is done means that GLIBC_2.3.2 is directly specified as
the version set in the declarations.  So you'll also have to override
nptl/forward.c in sysdeps/unix/sysv/linux/hppa/nptl/, probably just copy
and modify it.  For the affected functions there that have e.g.:

versioned_symbol (libc, __pthread_cond_broadcast, pthread_cond_broadcast,
		  GLIBC_2_3_2);

you need to change this to GLIBC_2_6 here.  That gets all the new functions
into the right version set.

Then for the existing compat stuff like:

#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_3_2)
strong_alias (__pthread_cond_broadcast, __pthread_cond_broadcast_2_0)
compat_symbol (libc, __pthread_cond_broadcast_2_0, pthread_cond_broadcast,
	       GLIBC_2_0);
#endif

You need to instead make it:

strong_alias (__pthread_cond_broadcast_2_3_2, __pthread_cond_broadcast_2_0)

Somewhere else like a new compat file you can define the compat routines:

	static void
	compat_mutex_init (pthread_mutex_t *p)
	{
	  if ((p->__data.__lock ^ p->__data.__pad[0]
	       ^ p->__data.__pad[1] ^ p->__data.__pad[2]) == 1)
	    p->__data.__lock = p->__data.__pad[0]
	      = p->__data.__pad[1] = p->__data.__pad[2] = 0;
	}

	int
	__pthread_mutex_lock_2_3_2 (pthread_mutex_t *p)
	{
	  compat_mutex_init (p);
	  return __pthread_mutex_lock (p);
	}

	...

That goes inside:
	 #ifdef SHLIB_COMPAT (libpthread, GLIBC_2_3_2, GLIBC_2_6)

Those same wrappers can go in libc (might as well be pulled into
forward.c), and there SHLIB_COMPAT (libc, ...) is what needs to be tested.
(You could use some more macro testing and #include the same source into
forward.c for libc.so that is compiled as an extra object for libpthread.)

Because of versioned_symbol uses you'll need to add wrapper files for
pthread_cond_destroy.c et al that define the functions whose version set
you're changing (only the ones that use versioned_symbol).  They can do:

#ifndef INCLUDED_SELF
# define INCLUDED_SELF
# include <pthread_cond_destroy.c>
#else
# include <shlib-compat.h>
# undef GLIBC_2_3_2
# define GLIBC_2_3_2 GLIBC_2_6
# include_next <pthread_cond_destroy.c>
#endif

I think that about covers it.


Thanks,
Roland
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 853 bytes --]

On Thursday 22 February 2007, Roland McGrath wrote:
> > All statically initialized locks are broken. We made locks smaller,
> > and changed the value of the static initialization.
>
> Smaller?  Smaller is easy.  And you didn't actually reduce
> __SIZEOF_PTHREAD_MUTEX_T, did you?  This seems like it would not be at all
> hard to accommodate just with symbol versioning and not break any
> compatibility.  Off hand, it seems like it would be some simple code in one
> new file in your sysdeps/ tree and a smattering of sysdeps Versions files.

how can you do symbol versioning on static initializers ?  the initialized 
value is compiled into the .data sections of the actual binary ...

hmm ... do you mean we retain the pthread code that uses the old locking 
methods and create all the new code with glibc-2.6 symbol versions ?
-mike

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Roland McGrath]

> All statically initialized locks are broken. We made locks smaller,
> and changed the value of the static initialization.

Smaller?  Smaller is easy.  And you didn't actually reduce
__SIZEOF_PTHREAD_MUTEX_T, did you?  This seems like it would not be at all
hard to accommodate just with symbol versioning and not break any
compatibility.  Off hand, it seems like it would be some simple code in one
new file in your sysdeps/ tree and a smattering of sysdeps Versions files.

But if your community is happy with a soname change and not worrying about
its various impacts, by all means just do that.  It's a lovely thing to be
able to stop compiling in all the compat stuff.

To do that, all you need is sysdeps/unix/sysv/linux/hppa/nptl/shlib-versions:

hppa.*-.*-linux.*	libc=6.1		GLIBC_2.6
hppa.*-.*-linux.*	libpthread=0.1		GLIBC_2.6

If there is any linuxthreads configuration still possible, that would leave
it producing libc.so.6/libpthread.so.0.  If that really can never be any
more, probably better to put the libc line in
sysdeps/unix/sysv/linux/hppa/shlib-versions. 


Thanks,
Roland
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Helge Deller]

On Monday 19 February 2007, Jeff Bailey wrote:
> On 19/02/07, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > >> if the breakage is just in pthreads, i dont think the libc ABI needs to be
> > >> bumped, just the pthread one ?  libc provides look ahead stub functions for
> > >> pthreads, so it shouldnt be affected by the breakage you've mentioned with
> > >> static lock initializers ...
> > >>
> > >> libpthread.so.0 -> libpthread.so.1
> > >
> > > While it's definetly Ubuntu and Debian's problem, not upstream's,
> > > libpthread is bundled in the "libc6" package.  Bumping just the
> > > libpthread version will make packaging hard for those distros.  If
> > > there are other ABI breaking moves that need to be done that would
> > > cause a bump from libc6, doing them now would help sidestep the
> > > problem.
> >
> > Well I am thinking in splitting out libpthread.so.X from the libc6
> > package if the ABI breakage is confirmed. This is still a very
> > complicated transition, but I think far less packages are affected.
> 
> Well, the ABI breakage is confirmed.  I just remember people siting
> some other corner case problems with the ABI they wanted to change.
> Now would be a great time to change it all over if we need to do this.

Maybe relevant:

- [parisc-linux] [PATCH] fix up our compat semaphore operations
   http://lists.parisc-linux.org/pipermail/parisc-linux/2007-January/031125.html
- [parisc-linux] 64-bit long double support.
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-November/030629.html
- [parisc-linux] [patch] Remove magic constant from gas/tc-hppa.c   Jeff Bailey
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-October/030417.html
- [parisc-linux] Re: Looking at vfprintf.c and alloca.
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-July/029607.html 
   (make possible to get ELF64 later?)
- [parisc-linux] Close to mainline for hppa-linux TLS.
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/029171.html
- [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/029050.html
- Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/028953.html
   (passing complex types)
- [parisc-linux] ELF ABI Documents
   http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028803.html
   (ELF64 ABI?)
   
 
> > I am a bit busy right now, but I think we should put our transition
> > ideas (at least for Debian, and probably Ubuntu) on a wiki, for example
> > http://wiki.debian.org/HppaNptlTransition
> 
> Sounds good.  I've added doko to the cc: list.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Aurelien Jarno]

Jeff Bailey a écrit :
> On 19/02/07, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>> if the breakage is just in pthreads, i dont think the libc ABI needs to be
>>>> bumped, just the pthread one ?  libc provides look ahead stub functions for
>>>> pthreads, so it shouldnt be affected by the breakage you've mentioned with
>>>> static lock initializers ...
>>>>
>>>> libpthread.so.0 -> libpthread.so.1
>>> While it's definetly Ubuntu and Debian's problem, not upstream's,
>>> libpthread is bundled in the "libc6" package.  Bumping just the
>>> libpthread version will make packaging hard for those distros.  If
>>> there are other ABI breaking moves that need to be done that would
>>> cause a bump from libc6, doing them now would help sidestep the
>>> problem.
>> Well I am thinking in splitting out libpthread.so.X from the libc6
>> package if the ABI breakage is confirmed. This is still a very
>> complicated transition, but I think far less packages are affected.
> 
> Well, the ABI breakage is confirmed.  I just remember people siting
> some other corner case problems with the ABI they wanted to change.
> Now would be a great time to change it all over if we need to do this.

You mean on hppa? Do you remember the proposed changes, or the people
wanted to change that?

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Jeff Bailey]

On 19/02/07, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> if the breakage is just in pthreads, i dont think the libc ABI needs to be
> >> bumped, just the pthread one ?  libc provides look ahead stub functions for
> >> pthreads, so it shouldnt be affected by the breakage you've mentioned with
> >> static lock initializers ...
> >>
> >> libpthread.so.0 -> libpthread.so.1
> >
> > While it's definetly Ubuntu and Debian's problem, not upstream's,
> > libpthread is bundled in the "libc6" package.  Bumping just the
> > libpthread version will make packaging hard for those distros.  If
> > there are other ABI breaking moves that need to be done that would
> > cause a bump from libc6, doing them now would help sidestep the
> > problem.
>
> Well I am thinking in splitting out libpthread.so.X from the libc6
> package if the ABI breakage is confirmed. This is still a very
> complicated transition, but I think far less packages are affected.

Well, the ABI breakage is confirmed.  I just remember people siting
some other corner case problems with the ABI they wanted to change.
Now would be a great time to change it all over if we need to do this.

> I am a bit busy right now, but I think we should put our transition
> ideas (at least for Debian, and probably Ubuntu) on a wiki, for example
> http://wiki.debian.org/HppaNptlTransition

Sounds good.  I've added doko to the cc: list.

-- 
Jeff Bailey - http://www.raspberryginger.com/jbailey/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Aurelien Jarno]

Jeff Bailey a écrit :
> On 18/02/07, Mike Frysinger <vapier@gentoo.org> wrote:
>> if the breakage is just in pthreads, i dont think the libc ABI needs to be
>> bumped, just the pthread one ?  libc provides look ahead stub functions for
>> pthreads, so it shouldnt be affected by the breakage you've mentioned with
>> static lock initializers ...
>>
>> libpthread.so.0 -> libpthread.so.1
> 
> While it's definetly Ubuntu and Debian's problem, not upstream's,
> libpthread is bundled in the "libc6" package.  Bumping just the
> libpthread version will make packaging hard for those distros.  If
> there are other ABI breaking moves that need to be done that would
> cause a bump from libc6, doing them now would help sidestep the
> problem.

Well I am thinking in splitting out libpthread.so.X from the libc6
package if the ABI breakage is confirmed. This is still a very
complicated transition, but I think far less packages are affected.

I am a bit busy right now, but I think we should put our transition
ideas (at least for Debian, and probably Ubuntu) on a wiki, for example
http://wiki.debian.org/HppaNptlTransition

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Jeff Bailey]

On 18/02/07, Mike Frysinger <vapier@gentoo.org> wrote:
> if the breakage is just in pthreads, i dont think the libc ABI needs to be
> bumped, just the pthread one ?  libc provides look ahead stub functions for
> pthreads, so it shouldnt be affected by the breakage you've mentioned with
> static lock initializers ...
>
> libpthread.so.0 -> libpthread.so.1

While it's definetly Ubuntu and Debian's problem, not upstream's,
libpthread is bundled in the "libc6" package.  Bumping just the
libpthread version will make packaging hard for those distros.  If
there are other ABI breaking moves that need to be done that would
cause a bump from libc6, doing them now would help sidestep the
problem.

Tks.

-- 
Jeff Bailey - http://www.raspberryginger.com/jbailey/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]

On Sunday 18 February 2007, Carlos O'Donell wrote:
> NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
> have broken the pthread ABI.
> <snip>
> It has been recommended that we bump to libc6.1 for NPTL. Is that a
> good idea? Are there any comments about how to make such a transition
> smooth for debian, gentoo, and ubuntu?

if the breakage is just in pthreads, i dont think the libc ABI needs to be 
bumped, just the pthread one ?  libc provides look ahead stub functions for 
pthreads, so it shouldnt be affected by the breakage you've mentioned with 
static lock initializers ...

libpthread.so.0 -> libpthread.so.1
-mike

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.

[Roland McGrath]

> NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
> have broken the pthread ABI.

Please elaborate on exactly which types and entrypoints are incompatible.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux