From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 32244 invoked from network); 17 Apr 2020 17:35:09 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 17 Apr 2020 17:35:09 -0000 Received: (qmail 9484 invoked by uid 550); 17 Apr 2020 17:35:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9463 invoked from network); 17 Apr 2020 17:35:06 -0000 Date: Fri, 17 Apr 2020 13:34:54 -0400 From: Rich Felker To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200417173454.GJ11469@brightrain.aerifal.cx> References: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> <20200416031601.GR11469@brightrain.aerifal.cx> <0cf901d61408$deb5f950$9c21ebf0$@codeaurora.org> <20200416161746.GW11469@brightrain.aerifal.cx> <173801d614db$c2cd8310$48688930$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <173801d614db$c2cd8310$48688930$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl][hexagon] testing updates On Fri, Apr 17, 2020 at 12:15:13PM -0500, sidneym@codeaurora.org wrote: > > > > -----Original Message----- > > From: 'Rich Felker' > > 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 > > > > 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. 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