This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Roland McGrath" <roland at redhat dot com>
- Cc: libc-ports at sourceware dot org, debian-glibc at lists dot debian dot org, parisc-linux <parisc-linux at lists dot parisc-linux dot org>
- Date: Fri, 23 Feb 2007 11:39:10 -0500
- Subject: Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HpOCqKUpI5NaWaANIRkMMOwROvsFwX8u0ero0f75swoAYRWDvWGuqOIf9mwsGP8Jm1kazEnl93woSchHuJgkgDMK2Lc4JARv+R7wYfdY+0TenSVSEBzVgfBZ5ToYs692WCfyMCFknI/3oPGynRpFzISkV2AGOR6CyDj5PV2R/rQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RG2oCJk7mc76Z9OEduzYUeT0ozARUz6xtaY/CcQFjOviQmeRRaHzhzYhd7szatGQemerc7WvlL7+pVzQNtwzjg9cK8SRCDkD5Mak+QtmyP+PUaG+ZerOu6nIuCbB8TPd05X9Mk1Mo61A36BVCyNyDGS9r/5KkxT5onads1QL3Ik=
- References: <119aab440702222125m1f144002l2ec36c37b68da101@mail.gmail.com> <20070223130938.BA1BD180076@magilla.sf.frob.com>
On 2/23/07, Roland McGrath <roland@redhat.com> wrote:
> 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.
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?
Does this scenario exist:
__lock = 1, __futex = 1, __total_seq = 1, __wakeup_seq = 1, everything
else zero?
If it doesn't then I *could* detect the old style lock initialization
without adding the padding.
Cheers,
Carlos.