RE: [musl][hexagon] testing updates

[<sidneym@codeaurora.org>]

> -----Original Message-----
> From: 'Rich Felker' <dalias@libc.org>
> Sent: Thursday, April 16, 2020 11:18 AM
> To: sidneym@codeaurora.org
> Cc: musl@lists.openwall.com
> Subject: Re: [musl][hexagon] testing updates
> 
> On Thu, Apr 16, 2020 at 11:05:36AM -0500, sidneym@codeaurora.org wrote:
> >
> >
> > > -----Original Message-----
> > > From: Rich Felker <dalias@libc.org>
> > > Sent: Wednesday, April 15, 2020 10:16 PM
> > > To: sidneym@codeaurora.org
> > > Cc: musl@lists.openwall.com
> > > Subject: Re: [musl][hexagon] testing updates
> > >
> > > On Wed, Apr 15, 2020 at 10:10:20PM -0500, sidneym@codeaurora.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