Date: Fri, 17 Apr 2020 12:15:13 -0500 From: <sidneym@...eaurora.org> To: <musl@...ts.openwall.com> Subject: RE: [hexagon] testing updates > -----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. 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. Thanks, > 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.