* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702181143h682c78d9ra0d765b06e08a594@mail.gmail.com> @ 2007-02-18 22:33 ` Roland McGrath 2007-02-19 1:26 ` Mike Frysinger [not found] ` <200702182027.00027.vapier@gentoo.org> 2 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2007-02-18 22:33 UTC (permalink / raw) To: Carlos O'Donell Cc: libc-ports, Aurelien Jarno, debian-glibc, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702181143h682c78d9ra0d765b06e08a594@mail.gmail.com> 2007-02-18 22:33 ` [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads Roland McGrath @ 2007-02-19 1:26 ` Mike Frysinger [not found] ` <200702182027.00027.vapier@gentoo.org> 2 siblings, 0 replies; 13+ messages in thread From: Mike Frysinger @ 2007-02-19 1:26 UTC (permalink / raw) To: Carlos O'Donell Cc: debian-glibc, Aurelien Jarno, Roland McGrath, libc-ports, parisc-linux [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <200702182027.00027.vapier@gentoo.org>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] ` <200702182027.00027.vapier@gentoo.org> @ 2007-02-19 13:32 ` Jeff Bailey [not found] ` <5b2e36650702190532u680731e4j71fa272806343b17@mail.gmail.com> 1 sibling, 0 replies; 13+ messages in thread From: Jeff Bailey @ 2007-02-19 13:32 UTC (permalink / raw) To: Mike Frysinger Cc: debian-glibc, Aurelien Jarno, Roland McGrath, libc-ports, parisc-linux 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <5b2e36650702190532u680731e4j71fa272806343b17@mail.gmail.com>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] ` <5b2e36650702190532u680731e4j71fa272806343b17@mail.gmail.com> @ 2007-02-19 15:26 ` Aurelien Jarno [not found] ` <45D9C1AC.9000501@aurel32.net> 1 sibling, 0 replies; 13+ messages in thread From: Aurelien Jarno @ 2007-02-19 15:26 UTC (permalink / raw) To: Jeff Bailey Cc: libc-ports, Aurelien Jarno, Roland McGrath, debian-glibc, parisc-linux 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <45D9C1AC.9000501@aurel32.net>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] ` <45D9C1AC.9000501@aurel32.net> @ 2007-02-19 15:48 ` Jeff Bailey [not found] ` <5b2e36650702190748j1d9306e6mdbc6dc8ed210c4ab@mail.gmail.com> 1 sibling, 0 replies; 13+ messages in thread From: Jeff Bailey @ 2007-02-19 15:48 UTC (permalink / raw) To: Aurelien Jarno Cc: matthias.klose, libc-ports, Aurelien Jarno, Roland McGrath, debian-glibc, parisc-linux 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <5b2e36650702190748j1d9306e6mdbc6dc8ed210c4ab@mail.gmail.com>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] ` <5b2e36650702190748j1d9306e6mdbc6dc8ed210c4ab@mail.gmail.com> @ 2007-02-19 16:05 ` Aurelien Jarno 2007-02-19 17:57 ` Helge Deller 1 sibling, 0 replies; 13+ messages in thread From: Aurelien Jarno @ 2007-02-19 16:05 UTC (permalink / raw) To: Jeff Bailey Cc: matthias.klose, libc-ports, Roland McGrath, debian-glibc, parisc-linux 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] ` <5b2e36650702190748j1d9306e6mdbc6dc8ed210c4ab@mail.gmail.com> 2007-02-19 16:05 ` Aurelien Jarno @ 2007-02-19 17:57 ` Helge Deller 1 sibling, 0 replies; 13+ messages in thread From: Helge Deller @ 2007-02-19 17:57 UTC (permalink / raw) To: parisc-linux Cc: matthias.klose, debian-glibc, Aurelien Jarno, Roland McGrath, libc-ports 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <119aab440702190825y26ea8d5eib876818d9cb89c5d@mail.gmail.com>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702190825y26ea8d5eib876818d9cb89c5d@mail.gmail.com> @ 2007-02-19 18:20 ` John David Anglin 0 siblings, 0 replies; 13+ messages in thread From: John David Anglin @ 2007-02-19 18:20 UTC (permalink / raw) To: Carlos O'Donell Cc: matthias.klose, roland, libc-ports, dave.anglin, willy, debian-glibc, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <119aab440702181522p517493e0gd4dcc8be753fd225@mail.gmail.com>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702181522p517493e0gd4dcc8be753fd225@mail.gmail.com> @ 2007-02-23 2:42 ` Roland McGrath 0 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2007-02-23 2:42 UTC (permalink / raw) To: Carlos O'Donell Cc: libc-ports, Aurelien Jarno, debian-glibc, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20070223024202.1175E1800E4@magilla.sf.frob.com>]
* [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <20070223024202.1175E1800E4@magilla.sf.frob.com> @ 2007-02-23 11:46 ` Mike Frysinger 0 siblings, 0 replies; 13+ messages in thread From: Mike Frysinger @ 2007-02-23 11:46 UTC (permalink / raw) To: Roland McGrath; +Cc: libc-ports, Aurelien Jarno, debian-glibc, parisc-linux [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <119aab440702222125m1f144002l2ec36c37b68da101@mail.gmail.com>]
* Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702222125m1f144002l2ec36c37b68da101@mail.gmail.com> @ 2007-02-23 13:09 ` Roland McGrath 0 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2007-02-23 13:09 UTC (permalink / raw) To: Carlos O'Donell Cc: debian-glibc, libc-ports, Aurelien Jarno, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <119aab440702230839r74de6682ge0619c42d5606caf@mail.gmail.com>]
* Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702230839r74de6682ge0619c42d5606caf@mail.gmail.com> @ 2007-02-24 1:56 ` Roland McGrath 0 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2007-02-24 1:56 UTC (permalink / raw) To: Carlos O'Donell; +Cc: debian-glibc, libc-ports, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <119aab440702251847u29687878mff8770653cccbb35@mail.gmail.com>]
* Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads. [not found] <119aab440702251847u29687878mff8770653cccbb35@mail.gmail.com> @ 2007-02-26 6:45 ` Roland McGrath 0 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2007-02-26 6:45 UTC (permalink / raw) To: Carlos O'Donell; +Cc: debian-glibc, libc-ports, parisc-linux > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-02-26 6:45 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <119aab440702181143h682c78d9ra0d765b06e08a594@mail.gmail.com> 2007-02-18 22:33 ` [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads Roland McGrath 2007-02-19 1:26 ` Mike Frysinger [not found] ` <200702182027.00027.vapier@gentoo.org> 2007-02-19 13:32 ` Jeff Bailey [not found] ` <5b2e36650702190532u680731e4j71fa272806343b17@mail.gmail.com> 2007-02-19 15:26 ` Aurelien Jarno [not found] ` <45D9C1AC.9000501@aurel32.net> 2007-02-19 15:48 ` Jeff Bailey [not found] ` <5b2e36650702190748j1d9306e6mdbc6dc8ed210c4ab@mail.gmail.com> 2007-02-19 16:05 ` Aurelien Jarno 2007-02-19 17:57 ` Helge Deller [not found] <119aab440702190825y26ea8d5eib876818d9cb89c5d@mail.gmail.com> 2007-02-19 18:20 ` John David Anglin [not found] <119aab440702181522p517493e0gd4dcc8be753fd225@mail.gmail.com> 2007-02-23 2:42 ` Roland McGrath [not found] <20070223024202.1175E1800E4@magilla.sf.frob.com> 2007-02-23 11:46 ` Mike Frysinger [not found] <119aab440702222125m1f144002l2ec36c37b68da101@mail.gmail.com> 2007-02-23 13:09 ` Roland McGrath [not found] <119aab440702230839r74de6682ge0619c42d5606caf@mail.gmail.com> 2007-02-24 1:56 ` Roland McGrath [not found] <119aab440702251847u29687878mff8770653cccbb35@mail.gmail.com> 2007-02-26 6:45 ` Roland McGrath
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.