Date: Sat, 16 Apr 2016 13:09:34 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH v2] add powerpc64 port On Fri, Apr 15, 2016 at 10:38:33PM +0200, Szabolcs Nagy wrote: > * Szabolcs Nagy <nsz@...t70.net> [2016-04-14 15:42:13 +0200]: > > * Bobby Bingham <koorogi@...rogi.info> [2016-04-14 03:01:38 -0500]: > > > > > > How important is it to match glibc here? > > > > > > > i think we don't care about abi compat > > (but it might be interesting to check how much abi > > difference there is between glibc and musl, i can > > do this if i can build a musl+glibc toolchain) > > > > attached some c++ abi comparisions Thanks! > (the comparision was not entirely clean, it involved > various manual hacks, but most types and functions > should be compared correctly glibc vs musl) > > two interesting gcc warnings: > > powerpc64 elf_vrreg_t (both musl and glibc): > note: the ABI of passing aggregates with 16-byte alignment has changed in GCC 5 This could be mildly problematic, but it's in a junk interface that's unlikely to be used cross-library anyway. > x86_64 struct inotify_event (musl only): > note: the ABI of passing struct with a flexible array member has changed in GCC 4.4 This looks irrelevant; passing the struct by value does not make sense. > --- abi_type.powerpc64le.glibc 2016-04-15 21:00:27.432246225 +0100 > +++ abi_type.powerpc64le.musl 2016-04-15 20:57:39.000149371 +0100 > @@ -97 +96 @@ > -fexcept_t: unsigned int, unsigned int*, size (*) , align (*)  > +fexcept_t: unsigned long, unsigned long*, size (*) , align (*)  Is this right? > @@ -100,2 +99,2 @@ > -fpos_t: _G_fpos_t, _G_fpos_t*, size (*) , align (*)  > +fpos_t: _G_fpos64_t, _G_fpos64_t*, size (*) , align (*)  You should probably be testing with -D_FILE_OFFSET_BITS=64. musl implements that ABI, and it matters in a few places even on 64-bit archs, like here. > @@ -130 +130 @@ > -jmp_buf: __jmp_buf_tag*, __jmp_buf_tag (*) , size (*) , align (*)  > +jmp_buf: __jmp_buf_tag*, __jmp_buf_tag (*) , size (*) , align (*)  Let's fix at least alignment and hopefully size. > @@ -141 +141 @@ > -mcontext_t: mcontext_t, mcontext_t*, size (*) , align (*)  > +mcontext_t: sigcontext, sigcontext*, size (*) , align (*)  IIRC on other archs we made an effort to make the tag here match ABI (duplicating the struct def if needed). Not sure if it matters. > @@ -183,2 +183,2 @@ > -pthread_rwlockattr_t: pthread_rwlockattr_t, pthread_rwlockattr_t*, size (*) , align (*)  > +pthread_rwlockattr_t: pthread_rwlockattr_t, pthread_rwlockattr_t*, size (*) , align (*)  Alignment difference was unintentional here but seems bad to try to fix for existing archs and I don't want to make the pthread types arch-specific; actually I want to move them to the shared alltypes.h.in or new arch/generic* with just a dependency on 32/64 bit. > -pthread_spinlock_t: int, int volatile*, size (*) , align (*)  > +pthread_spinlock_t: int, int*, size (*) , align (*)  Did glibc add volatile here? IIRC it was not there to begin with. If so they broke their own C++ ABI. I'd like to change this too, and if glibc did change it without anyone noticing/caring, we probably could too. > @@ -195 +195 @@ > -sem_t: sem_t, sem_t*, size (*) , align (*)  > +sem_t: sem_t, sem_t*, size (*) , align (*)  > @@ -229,2 +229,2 @@ > -cmsghdr: cmsghdr, cmsghdr*, size (*) , align (*)  > +cmsghdr: cmsghdr, cmsghdr*, size (*) , align (*)  This is likely going to hit the same issue we're trying to debug on mips64. > @@ -416 +417 @@ > -ucontext_t: ucontext, ucontext*, size (*) , align (*)  > +ucontext_t: ucontext, ucontext*, size (*) , align (*)  This may be a real problem. ucontext_t is ABI between kernel and userspace and if it's wrong cancellation won't work right. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.