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=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,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 32440 invoked from network); 16 Apr 2020 03:10:39 -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; 16 Apr 2020 03:10:39 -0000 Received: (qmail 3514 invoked by uid 550); 16 Apr 2020 03:10:37 -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 3493 invoked from network); 16 Apr 2020 03:10:36 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1587006636; h=Content-Type: MIME-Version: Message-ID: Date: Subject: To: From: Sender; bh=k3+ohzyZJC52LifK6Ho5avqG3q/TrOI1RU7cfooxxno=; b=qE22fAWgTIo+YJgIKDiY4PNjFgzq++qQlFi6JASrelFVgi5Vd9stYXdTc8PKubFjvDmp7YqD ysic39NrIk27uOXKjnJNImmq99WslTmcQOnyCS+9ZOwXRbI/1d/1HVCOdm3m2HsaoDn4bFVl 0iKVmhBdk/eRL+YOWhlfbCzFiAs= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B171CC433F2 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: Date: Wed, 15 Apr 2020 22:10:20 -0500 Message-ID: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_093F_01D61372.A7E831E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYTnIPztUjHlp0JTKKVkpm0TtOVpQ== Content-Language: en-us Subject: [musl][hexagon] testing updates This is a multipart message in MIME format. ------=_NextPart_000_093F_01D61372.A7E831E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 src/regression/pthread_cond-smasher-static.exe src/regression/pthread_cond-smasher.exe src/regression/pthread_cond_wait-cancel_ignored-static.exe src/regression/pthread_cond_wait-cancel_ignored.exe src/regression/pthread_once-deadlock-static.exe The patch is here: https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ced6f37087 I will continue to examine the issues and follow up. Thanks, ------=_NextPart_000_093F_01D61372.A7E831E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

= src/regression/pthread_cond-smasher-static.exe

= src/regression/pthread_cond-smasher.exe

= src/regression/pthread_cond_wait-cancel_ignored-static.exe

= src/regression/pthread_cond_wait-cancel_ignored.exe

= src/regression/pthread_once-deadlock-static.exe

The patch is = here: https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51= c4cd00ced6f37087

I will = continue to examine the issues and follow up.

Thanks,

------=_NextPart_000_093F_01D61372.A7E831E0-- 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 767 invoked from network); 16 Apr 2020 03:16:17 -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; 16 Apr 2020 03:16:17 -0000 Received: (qmail 5937 invoked by uid 550); 16 Apr 2020 03:16:15 -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 5916 invoked from network); 16 Apr 2020 03:16:14 -0000 Date: Wed, 15 Apr 2020 23:16:01 -0400 From: Rich Felker To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200416031601.GR11469@brightrain.aerifal.cx> References: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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. > src/regression/pthread_cond-smasher-static.exe > > src/regression/pthread_cond-smasher.exe > > src/regression/pthread_cond_wait-cancel_ignored-static.exe > > src/regression/pthread_cond_wait-cancel_ignored.exe > > src/regression/pthread_once-deadlock-static.exe Likewise these shouldn't have changed either. If they did it's probably some other hidden state in your test environment. > The patch is here: > https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ced6f37087 The change to alltypes.h.in is wrong. It changes time_t to 32-bit, which is no longer a supported configuration and not the intent. With that part reverted and the sysvipc bits headers fixed as described before, I think you might have it mostly working. Rich 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=DKIM_SIGNED,DKIM_VALID, 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 3594 invoked from network); 16 Apr 2020 16:06:18 -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; 16 Apr 2020 16:06:18 -0000 Received: (qmail 27985 invoked by uid 550); 16 Apr 2020 16:06:15 -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 27945 invoked from network); 16 Apr 2020 16:06:13 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1587053175; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-ID: Date: Subject: In-Reply-To: References: Cc: To: From: Sender; bh=K/95RoUd+qp6y2afEACj4EpO/fX3pccZ38Du3PFVNYE=; b=H0tgqxalOitiTnNILvOtUXRrImYw1OYAZ5k7gHmLcaeZ8NF+iZbP79Jx5LXvb07HoHV6xTV2 wfutjXn6L1el7w3Jb4H+UYzszlFzM429O5pTKQke/oul0jYagTqP1UN+NOJTxpL4pNB75XuF oUpQOuCGvaDyBdDQ4FqjbFm7hYY= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 09239C433CB Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: "'Rich Felker'" Cc: References: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> <20200416031601.GR11469@brightrain.aerifal.cx> In-Reply-To: <20200416031601.GR11469@brightrain.aerifal.cx> Date: Thu, 16 Apr 2020 11:05:36 -0500 Message-ID: <0cf901d61408$deb5f950$9c21ebf0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKpvFrF4hnSMamzdQO/1o68IggQlgH84T+PpsSm7NA= Content-Language: en-us Subject: RE: [musl][hexagon] testing updates > -----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. 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. > > > src/regression/pthread_cond-smasher-static.exe > > > > src/regression/pthread_cond-smasher.exe > > > > src/regression/pthread_cond_wait-cancel_ignored-static.exe > > > > src/regression/pthread_cond_wait-cancel_ignored.exe > > > > src/regression/pthread_once-deadlock-static.exe > > Likewise these shouldn't have changed either. If they did it's probably some > other hidden state in your test environment. > > > The patch is here: > > > https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ce > d6 > > f37087 > > The change to alltypes.h.in is wrong. It changes time_t to 32-bit, which is no > longer a supported configuration and not the intent. With that part reverted > and the sysvipc bits headers fixed as described before, I think you might > have it mostly working. > > Rich 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 4916 invoked from network); 16 Apr 2020 16:18:01 -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; 16 Apr 2020 16:18:01 -0000 Received: (qmail 20316 invoked by uid 550); 16 Apr 2020 16:17:59 -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 20298 invoked from network); 16 Apr 2020 16:17:58 -0000 Date: Thu, 16 Apr 2020 12:17:46 -0400 From: 'Rich Felker' To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200416161746.GW11469@brightrain.aerifal.cx> References: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> <20200416031601.GR11469@brightrain.aerifal.cx> <0cf901d61408$deb5f950$9c21ebf0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cf901d61408$deb5f950$9c21ebf0$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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. Rich 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=DKIM_SIGNED,DKIM_VALID, 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 29905 invoked from network); 17 Apr 2020 17:15:46 -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:15:46 -0000 Received: (qmail 1634 invoked by uid 550); 17 Apr 2020 17:15:44 -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 1616 invoked from network); 17 Apr 2020 17:15:41 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1587143744; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-ID: Date: Subject: In-Reply-To: References: To: From: Sender; bh=IbfmYrQsp+n/otGGYR+tTlBVDru59/qDM6o2jcUFGSk=; b=WuEX9U3Q1XQeShk9VZeKyuHcLHTAuTfZcNG4SnOwY0DknvM2p6U506O1yF7F8jiZbq6aDgya tFEvgSrViqwEyYiKUjtJ9EOXnVo9/NTjJvXXqyPfwFveJhRQkgXRkOqkWlkA53Ge6heVhKEC avF11RQ7ble1LRPmi19H8A5FPVE= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 29EB9C432C2 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: References: <093e01d6139c$90bd9da0$b238d8e0$@codeaurora.org> <20200416031601.GR11469@brightrain.aerifal.cx> <0cf901d61408$deb5f950$9c21ebf0$@codeaurora.org> <20200416161746.GW11469@brightrain.aerifal.cx> In-Reply-To: <20200416161746.GW11469@brightrain.aerifal.cx> Date: Fri, 17 Apr 2020 12:15:13 -0500 Message-ID: <173801d614db$c2cd8310$48688930$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKpvFrF4hnSMamzdQO/1o68IggQlgH84T+PAczPG+ECBluJkaansU7A Content-Language: en-us Subject: RE: [musl][hexagon] testing updates > -----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. 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 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