> 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 th
On 2/23/07, Roland McGrath <[EMAIL PROTECTED]> wrote:
> 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?
> 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'
On 2/23/07, Roland McGrath <[EMAIL PROTECTED]> 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
> 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 followi
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
On 2/22/07, Roland McGrath <[EMAIL PROTECTED]> 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 woul
> 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 ver
> 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 [EMAIL PROTECTED]
National Research Council of
On Monday 19 February 2007, Jeff Bailey wrote:
> On 19/02/07, Aurelien Jarno <[EMAIL PROTECTED]> 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
> > >> pthread
On 2/19/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> 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 reme
Jeff Bailey a écrit :
> On 19/02/07, Aurelien Jarno <[EMAIL PROTECTED]> 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 y
On 19/02/07, Aurelien Jarno <[EMAIL PROTECTED]> 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
>> stat
Jeff Bailey a écrit :
> On 18/02/07, Mike Frysinger <[EMAIL PROTECTED]> 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
On 18/02/07, Mike Frysinger <[EMAIL PROTECTED]> 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 init
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.
>
> It has been recommended that we bump to libc6.1 for NPTL. Is that a
> good idea? Are there any comments about how to ma
On 2/18/07, Roland McGrath <[EMAIL PROTECTED]> wrote:
> 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.
All statically initialized locks are broken. W
> 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
have broken the pthread ABI.
I made the choice. I told people we were breaking the ABI. We even
looked at weird alternatives. In the end I felt we could not sanely
support NPTL with "load and clear word" primitives.
19 matches
Mail list logo
