[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
