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=-2.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RDNS_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 21689 invoked from network); 12 Mar 2020 11:10:00 -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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 12 Mar 2020 11:10:00 -0000 Received: (qmail 20283 invoked by uid 550); 12 Mar 2020 11:09:57 -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 20252 invoked from network); 12 Mar 2020 11:09:56 -0000 From: "chengzhiwei (C)" To: "musl@lists.openwall.com" Thread-Topic: musl support riscv32 Thread-Index: AdX4XohuDtvAenakR26cwKk58m2sZg== Date: Thu, 12 Mar 2020 11:09:37 +0000 Message-ID: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.220.24] Content-Type: multipart/alternative; boundary="_000_7D9266CBFB4E9A4B9C7B1D0341567D8601727F45DGGEMI529MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [musl] musl support riscv32 --_000_7D9266CBFB4E9A4B9C7B1D0341567D8601727F45DGGEMI529MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbDoNClJlY2VudGx5LCB3ZSBkaWQgYSBzdXJ2ZXkgYWJvdXQgbXVzbCBsaWIgc3VwcG9y dGVkIGJ5IHRoZSB0YXJnZXQgb2YgcmlzY3YuIEFzIHdlIGtub3csICBtdXNsLXJpc2N2NjQgd2Fz IHJlbGVhc2VkIGxhc3QgeWVhciwgaXQncyBhIGdyZWF0IGpvYjoNCmh0dHBzOi8vZ2l0Lm11c2wt bGliYy5vcmcvY2dpdC9tdXNsL2NvbW1pdC8/aWQ9MGE0ODg2MGMyN2E4ZWIyOTFiY2M3NjE2ZWE5 ZWIwNzNkYzY2MGNhYg0KDQpCdXQgd2Ugd2FudCB0byBrbm93IHdoZW4gbXVzbCB3aWxsIHN1b3Bv cnQgcmlzY3YtMzIgdGFyZ2V0IGFuZCBiZSByZWxlYXNlZCBpbiB0aGUgY29tbXVuaXR5IGJhc2Vk IG9uIHRoZSBsYXRlc3QgdmVyc2lvbj8NCkZyb20gdGhlIGNvbW11bml0eSwgd2UgZm91bmQgdGhh dCB0aGUgcHJldmlvdXMgYnJhbmNoIHZlcnNpb24gc3VwcG9ydGVkIDMyIGJpdHMgYmFja2VuZCwN Cmh0dHBzOi8vZ2l0aHViLmNvbS9yaXNjdi9yaXNjdi1tdXNsL3RyZWUvcmlzY3YtbXVzbC0xLjEu MTgNCmh0dHBzOi8vZ2l0aHViLmNvbS9yaXNjdi9yaXNjdi1tdXNsL3RyZWUvcmlzY3YtbXVzbC0x LjEuMjANCkkgZ3Vlc3MgdGhlcmUgYXJlIHN0aWxsIGxvdHMgb2YgdGVzdHMgdG8gYmUgZG9uZSBm b3Igc3RhYmlsaXR5IHJlYXNvbnMuIE5leHQgcmVsZWFzZSBjYW4gc3VwcG9ydCByaXNjdi0zMiB0 YXJnZXQ/DQoNCk1heWJlIGl0J3Mgbm90IGFuIGVhc3kgam9iIGFib3V0IGF0b21pYyBvcGVyYXRp b24uICBJZiB0aGUgdmVyc2lvbiBzdXBwb3J0IGRhdGUgaXMgdW5jZXJ0YWluLCBjYW4geW91IHNo YXJlIHNvbWUgc29sdXRpb25zIHRvIGNpcmN1bXZlbnQgaXQ/DQpPdXIgdGVhbSBpcyBhbHNvIGNv bnNpZGVyaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBpbXBsZW1lbnRpbmcgdGhlIGZ1bmN0aW9uYWxp dHkgaW4gQyBjb2RlLCBjb3VsZCB5b3UgZ2l2ZSB1cyBzb21lIHN1Z2dlc3Rpb25zPw0KDQpIb3Bl IHlvdXIgcmVzcG9uc2WjoQ0KDQpBbGwgdGhlIGJlc3QsDQotLXpoaXdlaQ0KDQo= --_000_7D9266CBFB4E9A4B9C7B1D0341567D8601727F45DGGEMI529MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all:

Recently, we did a survey about= musl lib supported by the target of riscv. As we know,  musl-riscv64 = was released last year, it's a great job:

http= s://git.musl-libc.org/cgit/musl/commit/?id=3D0a48860c27a8eb291bcc7616ea9eb0= 73dc660cab

 

But we want to know when musl w= ill suoport riscv-32 target and be released in the community based on the l= atest version?

From the community, we found th= at the previous branch version supported 32 bits backend,

https://github.com/riscv/riscv-musl= /tree/riscv-musl-1.1.18

https://github.com/riscv/riscv-musl= /tree/riscv-musl-1.1.20

I guess there are still lots of= tests to be done for stability reasons. Next release can support riscv-32 = target?

 

Maybe it's not an easy job abou= t atomic operation.  If the version support date is uncertain, can you= share some solutions to circumvent it?

Our team is also considering th= e possibility of implementing the functionality in C code, could you give u= s some suggestions?

 

Hope your response=A3=A1

 

All the best,=

--zhiwei

 

--_000_7D9266CBFB4E9A4B9C7B1D0341567D8601727F45DGGEMI529MBXchi_-- 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=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 9330 invoked from network); 12 Mar 2020 13:57:30 -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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 12 Mar 2020 13:57:30 -0000 Received: (qmail 17666 invoked by uid 550); 12 Mar 2020 13:57:28 -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 17645 invoked from network); 12 Mar 2020 13:57:27 -0000 Date: Thu, 12 Mar 2020 09:57:15 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200312135715.GK11469@brightrain.aerifal.cx> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl support riscv32 On Thu, Mar 12, 2020 at 11:09:37AM +0000, chengzhiwei (C) wrote: > Hi, all: > Recently, we did a survey about musl lib supported by the target of riscv. As we know, musl-riscv64 was released last year, it's a great job: > https://git.musl-libc.org/cgit/musl/commit/?id=0a48860c27a8eb291bcc7616ea9eb073dc660cab > > But we want to know when musl will suoport riscv-32 target and be released in the community based on the latest version? > From the community, we found that the previous branch version supported 32 bits backend, > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.18 > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.20 > I guess there are still lots of tests to be done for stability reasons. Next release can support riscv-32 target? > > Maybe it's not an easy job about atomic operation. If the version support date is uncertain, can you share some solutions to circumvent it? > Our team is also considering the possibility of implementing the functionality in C code, could you give us some suggestions? > > Hope your response！ The main blocker for riscv32 has been that the kernel has not declared it a stable ABI yet. At the time it was first proposed, there were still problems related to it being a 32-bit arch with no legacy 32-bit time_t syscalls, but that's not an issue now. I'd be happy to look at an updated riscv32 port now (ideally based on what's upstram in musl for riscv64, converted to 32-bit, rather than the old proposal, since lots of bugs were fixed after it was merged) and hopefully convince Linus/kernel ppl to consider it stabilized on the basis that there's a libc ready to use it. 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=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 2647 invoked from network); 13 Mar 2020 02:05:33 -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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 13 Mar 2020 02:05:33 -0000 Received: (qmail 24159 invoked by uid 550); 13 Mar 2020 02:05:30 -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 24129 invoked from network); 13 Mar 2020 02:05:29 -0000 From: "chengzhiwei (C)" To: "musl@lists.openwall.com" CC: "liuyingying (F)" Thread-Topic: [musl] musl support riscv32 Thread-Index: AdX4XohuDtvAenakR26cwKk58m2sZv//qRiA//67VGA= Date: Fri, 13 Mar 2020 02:05:09 +0000 Message-ID: <7D9266CBFB4E9A4B9C7B1D0341567D8601728046@DGGEMI529-MBX.china.huawei.com> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> In-Reply-To: <20200312135715.GK11469@brightrain.aerifal.cx> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.220.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [musl] =?utf-8?B?562U5aSNOiBbbXVzbF0gbXVzbCBzdXBwb3J0IHJpc2N2MzI=?= VGhhbmtzLCBIb3BlZnVsbHkgSSBhbSEgDQoNCkFub3RoZXIgdGhpbmcgaXMgYWJvdXQgYXRvbWlj IG9wZXJhdGlvbihpZiAzMi1iaXQgYmFzZWQgb24gd2hhdCdzIHVwc3RyYW0gaW4gbXVzbCBmb3Ig cmlzY3Y2NCksIG11c2wncyBhdG9taWMgb3BlcmF0aW9uIGZvciByaXNjdjY0IGlzIGEgaGFuZHdy aXR0ZW4gYXNzZW1ibHkgdmVyc2lvbiwgYnV0IHNvbWUgUklTQ1YtViBNQ1Ugb21pdCBzdWNoIGlu c3RydWN0aW9ucyBMUi9TQyBzcGVjaWZpZWQgaW4gdGhlIEEgc3RhbmRhcmQgZXh0ZW5zaW9uLg0K U29tZW9uZSBkbyByZWxhdGVkIHdvcmsgdG8gc3VwcG9ydCBwcm9jZXNzb3JzIHdpdGhvdXQgYXRv bWljIGluc3RydWN0aW9ucz8gT3IgY29uc2lkZXJpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIGltcGxl bWVudGluZyB0aGUgZnVuY3Rpb25hbGl0eSBpbiBDIGNvZGUuDQoNCnpoaXdlaSANCg0KLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBSaWNoIEZlbGtlciBbbWFpbHRvOmRhbGlhc0Bs aWJjLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQz5pyIMTLml6UgMjE6NTcNCuaUtuS7tuS6 ujogbXVzbEBsaXN0cy5vcGVud2FsbC5jb20NCuS4u+mimDogUmU6IFttdXNsXSBtdXNsIHN1cHBv cnQgcmlzY3YzMg0KDQpPbiBUaHUsIE1hciAxMiwgMjAyMCBhdCAxMTowOTozN0FNICswMDAwLCBj aGVuZ3poaXdlaSAoQykgd3JvdGU6DQo+IEhpLCBhbGw6DQo+IFJlY2VudGx5LCB3ZSBkaWQgYSBz dXJ2ZXkgYWJvdXQgbXVzbCBsaWIgc3VwcG9ydGVkIGJ5IHRoZSB0YXJnZXQgb2YgcmlzY3YuIEFz IHdlIGtub3csICBtdXNsLXJpc2N2NjQgd2FzIHJlbGVhc2VkIGxhc3QgeWVhciwgaXQncyBhIGdy ZWF0IGpvYjoNCj4gaHR0cHM6Ly9naXQubXVzbC1saWJjLm9yZy9jZ2l0L211c2wvY29tbWl0Lz9p ZD0wYTQ4ODYwYzI3YThlYjI5MWJjYzc2MQ0KPiA2ZWE5ZWIwNzNkYzY2MGNhYg0KPiANCj4gQnV0 IHdlIHdhbnQgdG8ga25vdyB3aGVuIG11c2wgd2lsbCBzdW9wb3J0IHJpc2N2LTMyIHRhcmdldCBh bmQgYmUgcmVsZWFzZWQgaW4gdGhlIGNvbW11bml0eSBiYXNlZCBvbiB0aGUgbGF0ZXN0IHZlcnNp b24/DQo+IEZyb20gdGhlIGNvbW11bml0eSwgd2UgZm91bmQgdGhhdCB0aGUgcHJldmlvdXMgYnJh bmNoIHZlcnNpb24gDQo+IHN1cHBvcnRlZCAzMiBiaXRzIGJhY2tlbmQsDQo+IGh0dHBzOi8vZ2l0 aHViLmNvbS9yaXNjdi9yaXNjdi1tdXNsL3RyZWUvcmlzY3YtbXVzbC0xLjEuMTgNCj4gaHR0cHM6 Ly9naXRodWIuY29tL3Jpc2N2L3Jpc2N2LW11c2wvdHJlZS9yaXNjdi1tdXNsLTEuMS4yMA0KPiBJ IGd1ZXNzIHRoZXJlIGFyZSBzdGlsbCBsb3RzIG9mIHRlc3RzIHRvIGJlIGRvbmUgZm9yIHN0YWJp bGl0eSByZWFzb25zLiBOZXh0IHJlbGVhc2UgY2FuIHN1cHBvcnQgcmlzY3YtMzIgdGFyZ2V0Pw0K PiANCj4gTWF5YmUgaXQncyBub3QgYW4gZWFzeSBqb2IgYWJvdXQgYXRvbWljIG9wZXJhdGlvbi4g IElmIHRoZSB2ZXJzaW9uIHN1cHBvcnQgZGF0ZSBpcyB1bmNlcnRhaW4sIGNhbiB5b3Ugc2hhcmUg c29tZSBzb2x1dGlvbnMgdG8gY2lyY3VtdmVudCBpdD8NCj4gT3VyIHRlYW0gaXMgYWxzbyBjb25z aWRlcmluZyB0aGUgcG9zc2liaWxpdHkgb2YgaW1wbGVtZW50aW5nIHRoZSBmdW5jdGlvbmFsaXR5 IGluIEMgY29kZSwgY291bGQgeW91IGdpdmUgdXMgc29tZSBzdWdnZXN0aW9ucz8NCj4gDQo+IEhv cGUgeW91ciByZXNwb25zZe+8gQ0KDQpUaGUgbWFpbiBibG9ja2VyIGZvciByaXNjdjMyIGhhcyBi ZWVuIHRoYXQgdGhlIGtlcm5lbCBoYXMgbm90IGRlY2xhcmVkIGl0IGEgc3RhYmxlIEFCSSB5ZXQu IEF0IHRoZSB0aW1lIGl0IHdhcyBmaXJzdCBwcm9wb3NlZCwgdGhlcmUgd2VyZSBzdGlsbCBwcm9i bGVtcyByZWxhdGVkIHRvIGl0IGJlaW5nIGEgMzItYml0IGFyY2ggd2l0aCBubyBsZWdhY3kgMzIt Yml0IHRpbWVfdCBzeXNjYWxscywgYnV0IHRoYXQncyBub3QgYW4gaXNzdWUgbm93LiBJJ2QgYmUg aGFwcHkgdG8gbG9vayBhdCBhbiB1cGRhdGVkIHJpc2N2MzIgcG9ydCBub3cgKGlkZWFsbHkgYmFz ZWQgb24gd2hhdCdzIHVwc3RyYW0gaW4gbXVzbCBmb3IgcmlzY3Y2NCwgY29udmVydGVkIHRvIDMy LWJpdCwgcmF0aGVyIHRoYW4gdGhlIG9sZCBwcm9wb3NhbCwgc2luY2UgbG90cyBvZiBidWdzIHdl cmUgZml4ZWQgYWZ0ZXIgaXQgd2FzIG1lcmdlZCkgYW5kIGhvcGVmdWxseSBjb252aW5jZSBMaW51 cy9rZXJuZWwgcHBsIHRvIGNvbnNpZGVyIGl0IHN0YWJpbGl6ZWQgb24gdGhlIGJhc2lzIHRoYXQg dGhlcmUncyBhIGxpYmMgcmVhZHkgdG8gdXNlIGl0Lg0KDQpSaWNoDQo= 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=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 3678 invoked from network); 13 Mar 2020 02:13:33 -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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 13 Mar 2020 02:13:33 -0000 Received: (qmail 26533 invoked by uid 550); 13 Mar 2020 02:13:31 -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 26515 invoked from network); 13 Mar 2020 02:13:31 -0000 Date: Thu, 12 Mar 2020 22:13:18 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200313021318.GL11469@brightrain.aerifal.cx> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> <7D9266CBFB4E9A4B9C7B1D0341567D8601728046@DGGEMI529-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D9266CBFB4E9A4B9C7B1D0341567D8601728046@DGGEMI529-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] =?utf-8?B?562U5aSN?= =?utf-8?Q?=3A?= [musl] musl support riscv32 On Fri, Mar 13, 2020 at 02:05:09AM +0000, chengzhiwei (C) wrote: > Thanks, Hopefully I am! > > Another thing is about atomic operation(if 32-bit based on what's > upstram in musl for riscv64), musl's atomic operation for riscv64 is > a handwritten assembly version, but some RISCV-V MCU omit such > instructions LR/SC specified in the A standard extension. Someone do > related work to support processors without atomic instructions? Or > considering the possibility of implementing the functionality in C > code. If the hardware lacks them the kernel needs to trap and emulate, or provide some other mechanism (like kuser_helper on old ARM). There's no way to have a working implementation without compare-and-swap. I've said many times that it's ridiculous that RISC-V made them optional. For a single-core CPU LR/SC are trivial to implement. LR just sets a flag and all interrupts clear the flag. SC stores only if the flag is set. 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=-1.5 required=5.0 tests=MAILING_LIST_MULTI,PDS_BTC_ID, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 32453 invoked from network); 13 Mar 2020 06:03: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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 13 Mar 2020 06:03:18 -0000 Received: (qmail 23613 invoked by uid 550); 13 Mar 2020 06:03: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 23589 invoked from network); 13 Mar 2020 06:03:14 -0000 Date: Fri, 13 Mar 2020 14:02:41 +0800 From: Ruinland ChuanTzu Tsai To: CC: Message-ID: <20200313060241.GB3971@APC301.andestech.com> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> <202003130543.02D5h9Zk085624@ATCSQR.andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202003130543.02D5h9Zk085624@ATCSQR.andestech.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.0.12.128] X-DNSRBL: X-MAIL:ATCSQR.andestech.com 02D652pl091005 Subject: Re: [musl] musl support riscv32 Hi zhiwei all, We (Andes Technology) have been porting Drew and others' work on musl for RV32 to 1.2.0. For now it can boot a busybox based RV32 Linux successfully and it passed most of the libc-test cases. Further verification on our inhouse port is undergoing. I think that wrapping atomic handling (e.g. LR/SC pair) is viable yet might need more discussion about the design. My colleague Simon is also in the CC list, so if zhiwei has interets about customizing such parts. We might work out together. By the way, there are some interesting work trying to add A extension without LR/SC to wimpy softcores. Such as Princeton's OpenPiton : https://github.com/PrincetonUniversity/openpiton/commit/3f8ba2600fb36032ddb9510c862e53c5bcf963fc#diff-3199fa5f89bf3b9db625bd88a6a6b8c6 Best regards, Ruinland On Fri, Mar 13, 2020 at 02:05:09AM +0000, chengzhiwei (C) wrote: > Thanks, Hopefully I am! > > Another thing is about atomic operation(if 32-bit based on what's upstram in musl for riscv64), musl's atomic operation for riscv64 is a handwritten assembly version, but some RISCV-V MCU omit such instructions LR/SC specified in the A standard extension. > Someone do related work to support processors without atomic instructions? Or considering the possibility of implementing the functionality in C code. > > zhiwei > > -----邮件原件----- > 发件人: Rich Felker [mailto:dalias@libc.org] > 发送时间: 2020年3月12日 21:57 > 收件人: musl@lists.openwall.com > 主题: Re: [musl] musl support riscv32 > > On Thu, Mar 12, 2020 at 11:09:37AM +0000, chengzhiwei (C) wrote: > > Hi, all: > > Recently, we did a survey about musl lib supported by the target of riscv. As we know, musl-riscv64 was released last year, it's a great job: > > https://git.musl-libc.org/cgit/musl/commit/?id=0a48860c27a8eb291bcc761 > > 6ea9eb073dc660cab > > > > But we want to know when musl will suoport riscv-32 target and be released in the community based on the latest version? > > From the community, we found that the previous branch version > > supported 32 bits backend, > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.18 > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.20 > > I guess there are still lots of tests to be done for stability reasons. Next release can support riscv-32 target? > > > > Maybe it's not an easy job about atomic operation. If the version support date is uncertain, can you share some solutions to circumvent it? > > Our team is also considering the possibility of implementing the functionality in C code, could you give us some suggestions? > > > > Hope your response！ > > The main blocker for riscv32 has been that the kernel has not declared it a stable ABI yet. At the time it was first proposed, there were still problems related to it being a 32-bit arch with no legacy 32-bit time_t syscalls, but that's not an issue now. I'd be happy to look at an updated riscv32 port now (ideally based on what's upstram in musl for riscv64, converted to 32-bit, rather than the old proposal, since lots of bugs were fixed after it was merged) and hopefully convince Linus/kernel ppl to consider it stabilized on the basis that there's a libc ready to use it. > > 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=-1.5 required=5.0 tests=MAILING_LIST_MULTI,PDS_BTC_ID, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 24611 invoked from network); 13 Mar 2020 14:05:19 -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 unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 13 Mar 2020 14:05:19 -0000 Received: (qmail 11490 invoked by uid 550); 13 Mar 2020 14:05:16 -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 11472 invoked from network); 13 Mar 2020 14:05:15 -0000 Date: Fri, 13 Mar 2020 10:05:03 -0400 From: Rich Felker To: Ruinland ChuanTzu Tsai Cc: musl@lists.openwall.com, wangtc@andestech.com Message-ID: <20200313140503.GM11469@brightrain.aerifal.cx> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> <202003130543.02D5h9Zk085624@ATCSQR.andestech.com> <20200313060241.GB3971@APC301.andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200313060241.GB3971@APC301.andestech.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl support riscv32 On Fri, Mar 13, 2020 at 02:02:41PM +0800, Ruinland ChuanTzu Tsai wrote: > Hi zhiwei all, > > We (Andes Technology) have been porting Drew and others' work on musl for RV32 to 1.2.0. > For now it can boot a busybox based RV32 Linux successfully and it passed most of the libc-test cases. > Further verification on our inhouse port is undergoing. > > > I think that wrapping atomic handling (e.g. LR/SC pair) is viable yet might need more discussion about the design. > My colleague Simon is also in the CC list, so if zhiwei has interets about customizing such parts. > We might work out together. > > By the way, there are some interesting work trying to add A extension without LR/SC to wimpy softcores. > Such as Princeton's OpenPiton : > https://github.com/PrincetonUniversity/openpiton/commit/3f8ba2600fb36032ddb9510c862e53c5bcf963fc#diff-3199fa5f89bf3b9db625bd88a6a6b8c6 Is there a reason they're not just implementing LR/SC for "wimpy softcores"? As long as you're not doing SMP it admits a trivial implementation, and it's much easier than doing the other A extensions which require support for instructions that can both load and store (which impacts the kind of pipeline architectures you can do, or requires support for microcoded instructions). Rich > On Fri, Mar 13, 2020 at 02:05:09AM +0000, chengzhiwei (C) wrote: > > Thanks, Hopefully I am! > > > > Another thing is about atomic operation(if 32-bit based on what's upstram in musl for riscv64), musl's atomic operation for riscv64 is a handwritten assembly version, but some RISCV-V MCU omit such instructions LR/SC specified in the A standard extension. > > Someone do related work to support processors without atomic instructions? Or considering the possibility of implementing the functionality in C code. > > > > zhiwei > > > > -----邮件原件----- > > 发件人: Rich Felker [mailto:dalias@libc.org] > > 发送时间: 2020年3月12日 21:57 > > 收件人: musl@lists.openwall.com > > 主题: Re: [musl] musl support riscv32 > > > > On Thu, Mar 12, 2020 at 11:09:37AM +0000, chengzhiwei (C) wrote: > > > Hi, all: > > > Recently, we did a survey about musl lib supported by the target of riscv. As we know, musl-riscv64 was released last year, it's a great job: > > > https://git.musl-libc.org/cgit/musl/commit/?id=0a48860c27a8eb291bcc761 > > > 6ea9eb073dc660cab > > > > > > But we want to know when musl will suoport riscv-32 target and be released in the community based on the latest version? > > > From the community, we found that the previous branch version > > > supported 32 bits backend, > > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.18 > > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.20 > > > I guess there are still lots of tests to be done for stability reasons. Next release can support riscv-32 target? > > > > > > Maybe it's not an easy job about atomic operation. If the version support date is uncertain, can you share some solutions to circumvent it? > > > Our team is also considering the possibility of implementing the functionality in C code, could you give us some suggestions? > > > > > > Hope your response！ > > > > The main blocker for riscv32 has been that the kernel has not declared it a stable ABI yet. At the time it was first proposed, there were still problems related to it being a 32-bit arch with no legacy 32-bit time_t syscalls, but that's not an issue now. I'd be happy to look at an updated riscv32 port now (ideally based on what's upstram in musl for riscv64, converted to 32-bit, rather than the old proposal, since lots of bugs were fixed after it was merged) and hopefully convince Linus/kernel ppl to consider it stabilized on the basis that there's a libc ready to use it. > > > > Rich