Date: Fri, 17 Apr 2020 13:34:54 -0400 From: Rich Felker <dalias@...c.org> To: sidneym@...eaurora.org Cc: musl@...ts.openwall.com Subject: Re: [hexagon] testing updates On Fri, Apr 17, 2020 at 12:15:13PM -0500, sidneym@...eaurora.org wrote: > > > > -----Original Message----- > > From: 'Rich Felker' <dalias@...c.org> > > Sent: Thursday, April 16, 2020 11:18 AM > > To: sidneym@...eaurora.org > > Cc: musl@...ts.openwall.com > > Subject: Re: [musl][hexagon] testing updates > > > > On Thu, Apr 16, 2020 at 11:05:36AM -0500, sidneym@...eaurora.org wrote: > > > > > > > > > > -----Original Message----- > > > > From: Rich Felker <dalias@...c.org> > > > > Sent: Wednesday, April 15, 2020 10:16 PM > > > > To: sidneym@...eaurora.org > > > > Cc: musl@...ts.openwall.com > > > > Subject: Re: [musl][hexagon] testing updates > > > > > > > > On Wed, Apr 15, 2020 at 10:10:20PM -0500, sidneym@...eaurora.org > > wrote: > > > > > Updated alltypes.h.in and added sem.h. This change cleared the > > > > > following > > > > > errors: > > > > > > > > > > src/functional/pthread_mutex-static.exe > > > > > > > > > > src/functional/pthread_mutex.exe > > > > > > > > > > src/functional/pthread_mutex_pi-static.exe > > > > > > > > > > src/functional/pthread_mutex_pi.exe > > > > > src/functional/sem_init-static.exe > > > > > > > > > > src/functional/sem_init.exe > > > > > > > > I'm confused how these changed at all from the changes you made. > > > > sem_init is for POSIX semaphores not sysv ipc ones. The bits/sem.h > > > > things don't have anything to do with it. > > > > > > The sem.h change shouldn't have been included in the patch. > > > The change of time_t from a 64 to 32 bit value changed the size of > > > timespec used in the pthread_cond and sem_timedwait > > > > > > I pruned our original port, possibly too much in some cases, but in > > > this case I'd like some guidance since no other arch needed time_t as > > > a 32-bit type. > > > > Remove the time_t and suseconds_t TYPEDEFs from alltypes.h.in. They are > > no longer allowed to vary per-arch. Then make sure you rebuild > > *everything* (libc, the test suite, any other code you're linking against > musl > > and trying to use). I'm pretty sure you have a mix of files that have been > > build with different things you've tried and that is the source of your > > problems. > > > > > There is a large chunk of code compat/time32 which I have not tried to > > > use yet but I have a feeling I might need to. > > > > These files are only used on archs that had an old ABI with 32-bit time_t, > > which I asked about before and you seemed to say you don't have. If you > > *do* actually have an existing ecosystem of stuff that possibly needs to > keep > > working, we need to figure out what that is and whether it's even possible > to > > support (it might not be if it's a mess/mix of different things you've > tried). If > > not then these files will not even be built and are not needed. > > > This isn't something I had understood very well. Since Hexagon's unistd.h > defines __ARCH_WANT_TIME32_SYSCALLS then we are using the old ABI I believe. No, that's a matter of what interfaces the kernel provides. It has nothing to do with musl always having 64-bit time_t. > At the moment I don't feel very strongly about maintaining this, that might > change the more I learn. I'm looking at what it would take to migrate away > from this. There's no reason to migrate away from that. It doesn't affect userspace applications at all; it's just a matter of syscall interface stability. If you want to remove them, it can only be done before there's a stable interface, and you would also have to remove the syscall numbers from musl's arch/hexagon/bits/syscall.h.in or musl will (rightly, by kernel stability policy) assume it can use them. 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.