From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11209 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: [MUSL] microMIPS32R2 O32 port Date: Wed, 5 Apr 2017 06:33:01 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_004_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_" X-Trace: blaine.gmane.org 1491374008 25976 195.159.176.226 (5 Apr 2017 06:33:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Apr 2017 06:33:28 +0000 (UTC) Cc: "musl@lists.openwall.com" , "nsz@port70.net" To: "dalias@libc.org" Original-X-From: musl-return-11224-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 05 08:33:24 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cveVI-0005Ly-BZ for gllmg-musl@m.gmane.org; Wed, 05 Apr 2017 08:33:16 +0200 Original-Received: (qmail 7587 invoked by uid 550); 5 Apr 2017 06:33:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7564 invoked from network); 5 Apr 2017 06:33:18 -0000 Thread-Topic: [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CA== Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11209 Archived-At: --_004_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_ Content-Type: multipart/alternative; boundary="_000_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_" --_000_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 = for microMIPS32R2 O32 port. I have also attached the patch (microMIPS32R2_v= 1_port.patch) for your reference. Could you please review it? Test result: FAIL ./src/api/main.exe [status 1] FAIL ./src/math/acosh.exe [status 1] FAIL ./src/math/acoshl.exe [status 1] FAIL ./src/math/asinh.exe [status 1] FAIL ./src/math/asinhl.exe [status 1] FAIL ./src/math/j0.exe [status 1] FAIL ./src/math/jn.exe [status 1] FAIL ./src/math/jnf.exe [status 1] FAIL ./src/math/lgamma.exe [status 1] FAIL ./src/math/lgamma_r.exe [status 1] FAIL ./src/math/lgammaf.exe [status 1] FAIL ./src/math/lgammaf_r.exe [status 1] FAIL ./src/math/lgammal.exe [status 1] FAIL ./src/math/sinh.exe [status 1] FAIL ./src/math/sinhl.exe [status 1] FAIL ./src/math/tgamma.exe [status 1] FAIL ./src/math/tgammal.exe [status 1] FAIL ./src/math/y0.exe [status 1] FAIL ./src/math/y0f.exe [status 1] FAIL ./src/math/ynf.exe [status 1] Thanks, Jaydeep --_000_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rich,

 

Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for microMIP= S32R2 O32 port. I have also attached the patch (microMIPS32R2_v1_port.patch= ) for your reference.

Could you please review it?

 

Test result:

 

FAIL ./src/api/main.exe [status 1]

FAIL ./src/math/acosh.exe [status 1]

FAIL ./src/math/acoshl.exe [status 1]

FAIL ./src/math/asinh.exe [status 1]

FAIL ./src/math/asinhl.exe [status 1]

FAIL ./src/math/j0.exe [status 1]

FAIL ./src/math/jn.exe [status 1]

FAIL ./src/math/jnf.exe [status 1]

FAIL ./src/math/lgamma.exe [status 1]

FAIL ./src/math/lgamma_r.exe [status 1]

FAIL ./src/math/lgammaf.exe [status 1]

FAIL ./src/math/lgammaf_r.exe [status 1]<= /p>

FAIL ./src/math/lgammal.exe [status 1]

FAIL ./src/math/sinh.exe [status 1]

FAIL ./src/math/sinhl.exe [status 1]

FAIL ./src/math/tgamma.exe [status 1]

FAIL ./src/math/tgammal.exe [status 1]

FAIL ./src/math/y0.exe [status 1]

FAIL ./src/math/y0f.exe [status 1]

FAIL ./src/math/ynf.exe [status 1]

 

Thanks,

Jaydeep

 

 

--_000_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_-- --_004_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_ Content-Type: application/octet-stream; name="microMIPS32R2_v1_port.patch" Content-Description: microMIPS32R2_v1_port.patch Content-Disposition: attachment; filename="microMIPS32R2_v1_port.patch"; size=10018; creation-date="Wed, 05 Apr 2017 05:52:47 GMT"; modification-date="Wed, 05 Apr 2017 05:52:47 GMT" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2FyY2gvbWlwcy9jcnRfYXJjaC5oIGIvYXJjaC9taXBzL2NydF9hcmNoLmgK aW5kZXggOWZjNTBkNy4uYzk1ZGIwNiAxMDA2NDQKLS0tIGEvYXJjaC9taXBzL2NydF9hcmNoLmgK KysrIGIvYXJjaC9taXBzL2NydF9hcmNoLmgKQEAgLTgsMTMgKzgsMzkgQEAgX19hc21fXygKICIu dHlwZSAgICIgU1RBUlQgIiwgQGZ1bmN0aW9uXG4iCiAiXyIgU1RBUlQgIjpcbiIKICIiIFNUQVJU ICI6XG4iCisjaWYgX19taXBzX2lzYV9yZXYgPCA2CisjaWZkZWYgX19taXBzX21pY3JvbWlwcwor Igltb3ZlICRmcCwgJDAgXG4iCisiCS5hbGlnbiAyIFxuIgorIgliYWwzMiAxZiBcbiIKKyIJbm9w MzIgXG4iCisjZWxzZQogIgliYWwgMWYgXG4iCiAiCSBtb3ZlICRmcCwgJDAgXG4iCisjZW5kaWYK KyNlbHNlCisiCW1vdmUgJGZwLCAkMCBcbiIKKyIJLmFsaWduIDIgXG4iCisiCWJhbGMgMWYgXG4i CisjZW5kaWYKICIJLmdwd29yZCAuIFxuIgogIgkuZ3B3b3JkICIgU1RBUlQgIl9jIFxuIgogIi53 ZWFrIF9EWU5BTUlDIFxuIgogIi5oaWRkZW4gX0RZTkFNSUMgXG4iCiAiCS5ncHdvcmQgX0RZTkFN SUMgXG4iCisKKyNpZmRlZiBfX21pcHNfbWljcm9taXBzCisiMToJaW5zICRyYSwgJDAsIDAsIDEg XG4iCisiCWx3ICRncCwgMCgkcmEpIFxuIgorIglzdWJ1ICRncCwgJHJhLCAkZ3AgXG4iCisiCW1v dmUgJDQsICRzcCBcbiIKKyIJbHcgJDUsIDgoJHJhKSBcbiIKKyIJYWRkdSAkNSwgJDUsICRncCBc biIKKyIJbHcgJDI1LCA0KCRyYSkgXG4iCisiCWFkZHUgJDI1LCAkMjUsICRncCBcbiIKKyIJb3Jp ICQyNSwgJDI1LCAxIFxuIgorIglhbmQgJHNwLCAkc3AsIC04IFxuIgorI2Vsc2UKICIxOglsdyAk Z3AsIDAoJHJhKSBcbiIKICIJc3VidSAkZ3AsICRyYSwgJGdwIFxuIgogIgltb3ZlICQ0LCAkc3Ag XG4iCkBAIC0yMyw3ICs0OSwxNCBAQCBfX2FzbV9fKAogIglsdyAkMjUsIDQoJHJhKSBcbiIKICIJ YWRkdSAkMjUsICQyNSwgJGdwIFxuIgogIglhbmQgJHNwLCAkc3AsIC04IFxuIgorI2VuZGlmCisK KyNpZiBfX21pcHNfaXNhX3JldiA8IDYKICIJamFsciAkMjUgXG4iCiAiCSBzdWJ1ICRzcCwgJHNw LCAxNiBcbiIKKyNlbHNlCisiCXN1YnUgJHNwLCAkc3AsIDE2IFxuIgorIglqYWxyYyAkMjUgXG4i CisjZW5kaWYKICIuc2V0IHBvcCBcbiIKICk7CmRpZmYgLS1naXQgYS9hcmNoL21pcHMvcmVsb2Mu aCBiL2FyY2gvbWlwcy9yZWxvYy5oCmluZGV4IGIzZDU5YTQuLjliNWE0ZDcgMTAwNjQ0Ci0tLSBh L2FyY2gvbWlwcy9yZWxvYy5oCisrKyBiL2FyY2gvbWlwcy9yZWxvYy5oCkBAIC0zNiw2ICszNiwy NiBAQAogI2RlZmluZSBDUlRKTVAocGMsc3ApIF9fYXNtX18gX192b2xhdGlsZV9fKCBcCiAJIm1v dmUgJHNwLCUxIDsganIgJTAiIDogOiAiciIocGMpLCAiciIoc3ApIDogIm1lbW9yeSIgKQogCisj aWYgX19taXBzX2lzYV9yZXYgPCA2CisjaWZkZWYgX19taXBzX21pY3JvbWlwcworI2RlZmluZSBH RVRGVU5DU1lNKGZwLCBzeW0sIGdvdCkgX19hc21fXyAoIFwKKwkiLmhpZGRlbiAiICNzeW0gIlxu IiBcCisJIi5zZXQgcHVzaCBcbiIgXAorCSIuc2V0IG5vcmVvcmRlciBcbiIgXAorCSIJLmFsaWdu IDIgXG4iIFwKKwkiCWJhbDMyIDFmIFxuIiBcCisJIgkgbm9wMzIgXG4iIFwKKwkiCS5ncHdvcmQg LiBcbiIgXAorCSIJLmdwd29yZCAiICNzeW0gIiBcbiIgXAorCSIxOglpbnMgJHJhLCAkMCwgMCwg MSBcbiIgXAorCSIJbHcgJTAsICgkcmEpIFxuIiBcCisJIglzdWJ1ICUwLCAkcmEsICUwIFxuIiBc CisJIglsdyAkcmEsIDQoJHJhKSBcbiIgXAorCSIJYWRkdSAlMCwgJTAsICRyYSBcbiIgXAorCSIJ b3JpICUwLCAlMCwgMSBcbiIgXAorCSIuc2V0IHBvcCBcbiIgXAorCTogIj1yIigqKGZwKSkgOiA6 ICJtZW1vcnkiLCAicmEiICkKKyNlbHNlCiAjZGVmaW5lIEdFVEZVTkNTWU0oZnAsIHN5bSwgZ290 KSBfX2FzbV9fICggXAogCSIuaGlkZGVuICIgI3N5bSAiXG4iIFwKIAkiLnNldCBwdXNoIFxuIiBc CkBAIC01MCwzICs3MCwzOCBAQAogCSIJYWRkdSAlMCwgJTAsICRyYSBcbiIgXAogCSIuc2V0IHBv cCBcbiIgXAogCTogIj1yIigqKGZwKSkgOiA6ICJtZW1vcnkiLCAicmEiICkKKyNlbmRpZgorI2Vs c2UKKyNpZmRlZiBfX21pcHNfbWljcm9taXBzCisjZGVmaW5lIEdFVEZVTkNTWU0oZnAsIHN5bSwg Z290KSBfX2FzbV9fICggXAorCSIuaGlkZGVuICIgI3N5bSAiXG4iIFwKKwkiLnNldCBwdXNoIFxu IiBcCisJIi5zZXQgbm9yZW9yZGVyIFxuIiBcCisJIgkuYWxpZ24gMiBcbiIgXAorCSIJYmFsYzMy IDFmIFxuIiBcCisJIgkuZ3B3b3JkIC4gXG4iIFwKKwkiCS5ncHdvcmQgIiAjc3ltICIgXG4iIFwK KwkiMToJaW5zICRyYSwgJDAsIDAsIDEgXG4iIFwKKwkiCWx3ICUwLCAoJHJhKSBcbiIgXAorCSIJ c3VidSAlMCwgJHJhLCAlMCBcbiIgXAorCSIJbHcgJHJhLCA0KCRyYSkgXG4iIFwKKwkiCWFkZHUg JTAsICUwLCAkcmEgXG4iIFwKKwkiCW9yaSAlMCwgJTAsIDEgXG4iIFwKKwkiLnNldCBwb3AgXG4i IFwKKwk6ICI9ciIoKihmcCkpIDogOiAibWVtb3J5IiwgInJhIiApCisjZWxzZQorI2RlZmluZSBH RVRGVU5DU1lNKGZwLCBzeW0sIGdvdCkgX19hc21fXyAoIFwKKwkiLmhpZGRlbiAiICNzeW0gIlxu IiBcCisJIi5zZXQgcHVzaCBcbiIgXAorCSIuc2V0IG5vcmVvcmRlciBcbiIgXAorCSIJYmFsYyAx ZiBcbiIgXAorCSIJLmdwd29yZCAuIFxuIiBcCisJIgkuZ3B3b3JkICIgI3N5bSAiIFxuIiBcCisJ IjE6CWx3ICUwLCAoJHJhKSBcbiIgXAorCSIJc3VidSAlMCwgJHJhLCAlMCBcbiIgXAorCSIJbHcg JHJhLCA0KCRyYSkgXG4iIFwKKwkiCWFkZHUgJTAsICUwLCAkcmEgXG4iIFwKKwkiLnNldCBwb3Ag XG4iIFwKKwk6ICI9ciIoKihmcCkpIDogOiAibWVtb3J5IiwgInJhIiApCisjZW5kaWYKKyNlbmRp ZgpkaWZmIC0tZ2l0IGEvY3J0L21pcHMvY3J0bi5zIGIvY3J0L21pcHMvY3J0bi5zCmluZGV4IDUw NmEwNGIuLjEwYmZhYTEgMTAwNjQ0Ci0tLSBhL2NydC9taXBzL2NydG4ucworKysgYi9jcnQvbWlw cy9jcnRuLnMKQEAgLTMsMTEgKzMsMTMgQEAKIC5zZWN0aW9uIC5pbml0CiAJbHcgJGdwLDI0KCRz cCkKIAlsdyAkcmEsMjgoJHNwKQotCWogJHJhCiAJYWRkdSAkc3AsJHNwLDMyCisJaiAkcmEKKwlu b3AKIAogLnNlY3Rpb24gLmZpbmkKIAlsdyAkZ3AsMjQoJHNwKQogCWx3ICRyYSwyOCgkc3ApCi0J aiAkcmEKIAlhZGR1ICRzcCwkc3AsMzIKKwlqICRyYQorCW5vcApkaWZmIC0tZ2l0IGEvc3JjL2Zl bnYvbWlwcy9mZW52LlMgYi9zcmMvZmVudi9taXBzL2ZlbnYuUwppbmRleCBhNWNiMWY1Li5iMDU0 OGFjIDEwMDY0NAotLS0gYS9zcmMvZmVudi9taXBzL2ZlbnYuUworKysgYi9zcmMvZmVudi9taXBz L2ZlbnYuUwpAQCAtMTAsOCArMTAsOSBAQCBmZWNsZWFyZXhjZXB0OgogCW9yICAgICAgJDUsICQ1 LCAkNAogCXhvciAgICAgJDUsICQ1LCAkNAogCWN0YzEgICAgJDUsICQzMQotCWpyICAgICAgJHJh CiAJbGkgICAgICAkMiwgMAorCWpyICAgICAgJHJhCisJbm9wCiAKIC5nbG9iYWwgZmVyYWlzZWV4 Y2VwdAogLnR5cGUgIGZlcmFpc2VleGNlcHQsQGZ1bmN0aW9uCkBAIC0yMCwyMyArMjEsMjYgQEAg ZmVyYWlzZWV4Y2VwdDoKIAljZmMxICAgICQ1LCAkMzEKIAlvciAgICAgICQ1LCAkNSwgJDQKIAlj dGMxICAgICQ1LCAkMzEKLQlqciAgICAgICRyYQogCWxpICAgICAgJDIsIDAKKwlqciAgICAgICRy YQorCW5vcAogCiAuZ2xvYmFsIGZldGVzdGV4Y2VwdAogLnR5cGUgIGZldGVzdGV4Y2VwdCxAZnVu Y3Rpb24KIGZldGVzdGV4Y2VwdDoKIAlhbmQgICAgICQ0LCAkNCwgMHg3YwogCWNmYzEgICAgJDIs ICQzMQotCWpyICAgICAgJHJhCiAJYW5kICAgICAkMiwgJDIsICQ0CisJanIgICAgICAkcmEKKwlu b3AKIAogLmdsb2JhbCBmZWdldHJvdW5kCiAudHlwZSAgZmVnZXRyb3VuZCxAZnVuY3Rpb24KIGZl Z2V0cm91bmQ6CiAJY2ZjMSAgICAkMiwgJDMxCi0JanIgICAgICAkcmEKIAlhbmRpICAgICQyLCAk MiwgMworCWpyICAgICAgJHJhCisJbm9wCiAKIC5nbG9iYWwgX19mZXNldHJvdW5kCiAudHlwZSBf X2Zlc2V0cm91bmQsQGZ1bmN0aW9uCkBAIC00NiwxNiArNTAsMTggQEAgX19mZXNldHJvdW5kOgog CWFuZCAgICAgJDUsICQ1LCAkNgogCW9yICAgICAgJDUsICQ1LCAkNAogCWN0YzEgICAgJDUsICQz MQotCWpyICAgICAgJHJhCiAJbGkgICAgICAkMiwgMAorCWpyICAgICAgJHJhCisJbm9wCiAKIC5n bG9iYWwgZmVnZXRlbnYKIC50eXBlICBmZWdldGVudixAZnVuY3Rpb24KIGZlZ2V0ZW52OgogCWNm YzEgICAgJDUsICQzMQogCXN3ICAgICAgJDUsIDAoJDQpCi0JanIgICAgICAkcmEKIAlsaSAgICAg ICQyLCAwCisJanIgICAgICAkcmEKKwlub3AKIAogLmdsb2JhbCBmZXNldGVudgogLnR5cGUgIGZl c2V0ZW52LEBmdW5jdGlvbgpAQCAtNjUsNyArNzEsOCBAQCBmZXNldGVudjoKIAkgbm9wCiAJbHcg ICAgICAkNSwgMCgkNCkKIDE6CWN0YzEgICAgJDUsICQzMQotCWpyICAgICAgJHJhCiAJbGkgICAg ICAkMiwgMAorCWpyICAgICAgJHJhCisJbm9wCiAKICNlbmRpZgpkaWZmIC0tZ2l0IGEvc3JjL2lu dGVybmFsL21pcHMvc3lzY2FsbC5zIGIvc3JjL2ludGVybmFsL21pcHMvc3lzY2FsbC5zCmluZGV4 IDVkMGRlZjUuLmU2Y2I4ZmIgMTAwNjQ0Ci0tLSBhL3NyYy9pbnRlcm5hbC9taXBzL3N5c2NhbGwu cworKysgYi9zcmMvaW50ZXJuYWwvbWlwcy9zeXNjYWxsLnMKQEAgLTE5LDggKzE5LDkgQEAgX19z eXNjYWxsOgogCXN3ICAgICAgJDIgLDI4KCRzcCkKIAlsdyAgICAgICQyLCAyOCgkc3ApCiAJc3lz Y2FsbAotCWJlcSAgICAgJDcsICQwLCAxZgogCWFkZHUgICAgJHNwLCAkc3AsIDMyCisJYmVxICAg ICAkNywgJDAsIDFmCisJbm9wCiAJc3VidSAgICAkMiwgJDAsICQyCiAxOglqciAgICAgICRyYQog CW5vcApkaWZmIC0tZ2l0IGEvc3JjL2xkc28vbWlwcy9kbHN5bS5zIGIvc3JjL2xkc28vbWlwcy9k bHN5bS5zCmluZGV4IDE1NzNlNTEuLmRkNjhhOGYgMTAwNjQ0Ci0tLSBhL3NyYy9sZHNvL21pcHMv ZGxzeW0ucworKysgYi9zcmMvbGRzby9taXBzL2Rsc3ltLnMKQEAgLTEzLDUgKzEzLDYgQEAgZGxz eW06CiAJamFsciAkMjUKIAlub3AKIAlsdyAkcmEsIDEyKCRzcCkKLQlqciAkcmEKIAlhZGRpdSAk c3AsICRzcCwgMTYKKwlqciAkcmEKKwlub3AKZGlmZiAtLWdpdCBhL3NyYy9zZXRqbXAvbWlwcy9s b25nam1wLlMgYi9zcmMvc2V0am1wL21pcHMvbG9uZ2ptcC5TCmluZGV4IGZkYjZjOTUuLmIxNTcy YzMgMTAwNjQ0Ci0tLSBhL3NyYy9zZXRqbXAvbWlwcy9sb25nam1wLlMKKysrIGIvc3JjL3NldGpt cC9taXBzL2xvbmdqbXAuUwpAQCAtMzYsNSArMzYsNiBAQCBsb25nam1wOgogCWx3ICAgICAgJDIy LCAzMigkNCkKIAlsdyAgICAgICQyMywgMzYoJDQpCiAJbHcgICAgICAkMzAsIDQwKCQ0KQotCWpy ICAgICAgJHJhCiAJbHcgICAgICAkMjgsIDQ0KCQ0KQorCWpyICAgICAgJHJhCisJbm9wCmRpZmYg LS1naXQgYS9zcmMvc2V0am1wL21pcHMvc2V0am1wLlMgYi9zcmMvc2V0am1wL21pcHMvc2V0am1w LlMKaW5kZXggNTAxZDUyNi4uZTQ1Yzc3ZCAxMDA2NDQKLS0tIGEvc3JjL3NldGptcC9taXBzL3Nl dGptcC5TCisrKyBiL3NyYy9zZXRqbXAvbWlwcy9zZXRqbXAuUwpAQCAtMzUsNSArMzUsNiBAQCBz ZXRqbXA6CiAJc3djMSAgICAkMzAsIDk2KCQ0KQogCXN3YzEgICAgJDMxLCAxMDAoJDQpCiAjZW5k aWYKLQlqciAgICAgICRyYQogCWxpICAgICAgJDIsIDAKKwlqciAgICAgICRyYQorCW5vcApkaWZm IC0tZ2l0IGEvc3JjL3NpZ25hbC9taXBzL3NpZ3NldGptcC5zIGIvc3JjL3NpZ25hbC9taXBzL3Np Z3NldGptcC5zCmluZGV4IDc0YjY1ZmYuLjZkN2I2MDUgMTAwNjQ0Ci0tLSBhL3NyYy9zaWduYWwv bWlwcy9zaWdzZXRqbXAucworKysgYi9zcmMvc2lnbmFsL21pcHMvc2lnc2V0am1wLnMKQEAgLTgs MTUgKzgsMTcgQEAgc2lnc2V0am1wOgogX19zaWdzZXRqbXA6CiAJbHVpICRncCwgJWhpKF9ncF9k aXNwKQogCWFkZGl1ICRncCwgJWxvKF9ncF9kaXNwKQorCWFkZHUgJGdwLCAkZ3AsICQyNQogCWJl cSAkNSwgJDAsIDFmCi0JIGFkZHUgJGdwLCAkZ3AsICQyNQorCSBub3AKIAogCXN3ICRyYSwgMTA0 KCQ0KQogCXN3ICQxNiwgMTA0KzQrMTYoJDQpCiAKIAlsdyAkMjUsICVjYWxsMTYoc2V0am1wKSgk Z3ApCisJbW92ZSAkMTYsICQ0CiAJamFsciAkMjUKLQkgbW92ZSAkMTYsICQ0CisJIG5vcAogCiAJ bW92ZSAkNSwkMgogCW1vdmUgJDQsJDE2CmRpZmYgLS1naXQgYS9zcmMvdGhyZWFkL21pcHMvY2xv bmUucyBiL3NyYy90aHJlYWQvbWlwcy9jbG9uZS5zCmluZGV4IDM3ZGRkZjUuLjhlODM2MjYgMTAw NjQ0Ci0tLSBhL3NyYy90aHJlYWQvbWlwcy9jbG9uZS5zCisrKyBiL3NyYy90aHJlYWQvbWlwcy9j bG9uZS5zCkBAIC00LDcgKzQsNyBAQAogX19jbG9uZToKIAkjIFNhdmUgZnVuY3Rpb24gcG9pbnRl ciBhbmQgYXJndW1lbnQgcG9pbnRlciBvbiBuZXcgdGhyZWFkIHN0YWNrCiAJYW5kICQ1LCAkNSwg LTgKLQlzdWJ1ICQ1LCAkNSwgMTYKKwlzdWJ1ICQ1LCAkNSwgMzIKIAlzdyAkNCwgMCgkNSkKIAlz dyAkNywgNCgkNSkKIAkjIFNodWZmbGUgKGZuLHNwLGZsLGFyZyxwdGlkLHRscyxjdGlkKSB0byAo Zmwsc3AscHRpZCx0bHMsY3RpZCkKQEAgLTE5LDggKzE5LDkgQEAgX19jbG9uZToKIAliZXEgJDcs ICQwLCAxZgogCW5vcAogCWFkZHUgJHNwLCAkc3AsIDE2Ci0JanIgJHJhCiAJc3VidSAkMiwgJDAs ICQyCisJanIgJHJhCisJbm9wCiAxOgliZXEgJDIsICQwLCAxZgogCW5vcAogCWFkZHUgJHNwLCAk c3AsIDE2CmRpZmYgLS1naXQgYS9zcmMvdGhyZWFkL21pcHMvc3lzY2FsbF9jcC5TIGIvc3JjL3Ro cmVhZC9taXBzL3N5c2NhbGxfY3AuUwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAw Li5jNTkzYmNmCi0tLSAvZGV2L251bGwKKysrIGIvc3JjL3RocmVhZC9taXBzL3N5c2NhbGxfY3Au UwpAQCAtMCwwICsxLDg1IEBACisuc2V0ICAgIG5vcmVvcmRlcgorCisuZ2xvYmFsIF9fY3BfYmVn aW4KKy5oaWRkZW4gX19jcF9iZWdpbgorLnR5cGUgICBfX2NwX2JlZ2luLEBmdW5jdGlvbgorLmds b2JhbCBfX2NwX2VuZAorLmhpZGRlbiBfX2NwX2VuZAorLnR5cGUgICBfX2NwX2VuZCxAZnVuY3Rp b24KKy5nbG9iYWwgX19jcF9jYW5jZWwKKy5oaWRkZW4gX19jcF9jYW5jZWwKKy50eXBlICAgX19j cF9jYW5jZWwsQGZ1bmN0aW9uCisuaGlkZGVuIF9fY2FuY2VsCisuZ2xvYmFsIF9fc3lzY2FsbF9j cF9hc20KKy5oaWRkZW4gX19zeXNjYWxsX2NwX2FzbQorLnR5cGUgICBfX3N5c2NhbGxfY3BfYXNt LEBmdW5jdGlvbgorX19zeXNjYWxsX2NwX2FzbToKKwlzdWJ1ICAgICRzcCwgJHNwLCAzMgorX19j cF9iZWdpbjoKKwlsdyAgICAgICQ0LCAwKCQ0KQorCW1vdmUgICAgJDIsICQ1CisJYm5lICAgICAk NCwgJDAsIF9fY3BfY2FuY2VsCisJbm9wCisJbW92ZSAgICAkNCwgJDYKKwltb3ZlICAgICQ1LCAk NworCWx3ICAgICAgJDYsIDQ4KCRzcCkKKwlsdyAgICAgICQ3LCA1Migkc3ApCisJbHcgICAgICAk OCwgNTYoJHNwKQorCWx3ICAgICAgJDksIDYwKCRzcCkKKwlsdyAgICAgICQxMCw2NCgkc3ApCisJ c3cgICAgICAkOCwgMTYoJHNwKQorCXN3ICAgICAgJDksIDIwKCRzcCkKKwlzdyAgICAgICQxMCwy NCgkc3ApCisJc3cgICAgICAkMiwgMjgoJHNwKQorCWx3ICAgICAgJDIsIDI4KCRzcCkKKwlzeXNj YWxsCitfX2NwX2VuZDoKKwlhZGR1ICAgICRzcCwgJHNwLCAzMgorCWJlcSAgICAgJDcsICQwLCAx ZgorCW5vcAorCXN1YnUgICAgJDIsICQwLCAkMgorMToJanIgICAgICAkcmEKKwlub3AKKworX19j cF9jYW5jZWw6CisJbW92ZSAgICAkMiwgJHJhCisKKyNpZiBfX21pcHNfaXNhX3JldiA8IDYKKyNp ZmRlZiBfX21pcHNfbWljcm9taXBzCisJYWRkdSAgICAkc3AsICRzcCwgMzIKKwkuYWxpZ24gIDIK KwliYWwzMiAgIDFmCisJbm9wMzIKKyNlbHNlCisJYmFsICAgICAxZgorCWFkZHUgICAgJHNwLCAk c3AsIDMyCisjZW5kaWYKKyNlbHNlCisjaWZkZWYgX19taXBzX21pY3JvbWlwcworCWFkZHUgICAg JHNwLCAkc3AsIDMyCisJLmFsaWduICAyCisJYmFsYzMyICAxZgorI2Vsc2UKKwlhZGR1ICAgICRz cCwgJHNwLCAzMgorCWJhbGMgICAgMWYKKyNlbmRpZgorI2VuZGlmCisJLmdwd29yZCAuCisJLmdw d29yZCBfX2NhbmNlbAorI2lmZGVmIF9fbWlwc19taWNyb21pcHMKKzE6CWlucyAgICAgJHJhLCAk MCwgMCwgMQorCWx3ICAgICAgJDMsICgkcmEpCisJc3VidSAgICAkMywgJHJhLCAkMworCWx3ICAg ICAgJDI1LCA0KCRyYSkKKwlhZGR1ICAgICQyNSwgJDI1LCAkMworCW9yaSAgICAgJDI1LCAkMjUs IDEKKyNlbHNlCisxOglsdyAgICAgICQzLCAoJHJhKQorCXN1YnUgICAgJDMsICRyYSwgJDMKKwls dyAgICAgICQyNSwgNCgkcmEpCisJYWRkdSAgICAkMjUsICQyNSwgJDMKKyNlbmRpZgorCW1vdmUg ICAgJHJhLCAkMgorCWpyICAgICAgJDI1CisKKwlub3AKZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQv bWlwcy9zeXNjYWxsX2NwLnMgYi9zcmMvdGhyZWFkL21pcHMvc3lzY2FsbF9jcC5zCmRlbGV0ZWQg ZmlsZSBtb2RlIDEwMDY0NAppbmRleCBkMjg0NjI2Li4wMDAwMDAwCi0tLSBhL3NyYy90aHJlYWQv bWlwcy9zeXNjYWxsX2NwLnMKKysrIC9kZXYvbnVsbApAQCAtMSw1MyArMCwwIEBACi0uc2V0ICAg IG5vcmVvcmRlcgotCi0uZ2xvYmFsIF9fY3BfYmVnaW4KLS5oaWRkZW4gX19jcF9iZWdpbgotLnR5 cGUgICBfX2NwX2JlZ2luLEBmdW5jdGlvbgotLmdsb2JhbCBfX2NwX2VuZAotLmhpZGRlbiBfX2Nw X2VuZAotLnR5cGUgICBfX2NwX2VuZCxAZnVuY3Rpb24KLS5nbG9iYWwgX19jcF9jYW5jZWwKLS5o aWRkZW4gX19jcF9jYW5jZWwKLS50eXBlICAgX19jcF9jYW5jZWwsQGZ1bmN0aW9uCi0uaGlkZGVu IF9fY2FuY2VsCi0uZ2xvYmFsIF9fc3lzY2FsbF9jcF9hc20KLS5oaWRkZW4gX19zeXNjYWxsX2Nw X2FzbQotLnR5cGUgICBfX3N5c2NhbGxfY3BfYXNtLEBmdW5jdGlvbgotX19zeXNjYWxsX2NwX2Fz bToKLQlzdWJ1ICAgICRzcCwgJHNwLCAzMgotX19jcF9iZWdpbjoKLQlsdyAgICAgICQ0LCAwKCQ0 KQotCWJuZSAgICAgJDQsICQwLCBfX2NwX2NhbmNlbAotCW1vdmUgICAgJDIsICQ1Ci0JbW92ZSAg ICAkNCwgJDYKLQltb3ZlICAgICQ1LCAkNwotCWx3ICAgICAgJDYsIDQ4KCRzcCkKLQlsdyAgICAg ICQ3LCA1Migkc3ApCi0JbHcgICAgICAkOCwgNTYoJHNwKQotCWx3ICAgICAgJDksIDYwKCRzcCkK LQlsdyAgICAgICQxMCw2NCgkc3ApCi0Jc3cgICAgICAkOCwgMTYoJHNwKQotCXN3ICAgICAgJDks IDIwKCRzcCkKLQlzdyAgICAgICQxMCwyNCgkc3ApCi0Jc3cgICAgICAkMiwgMjgoJHNwKQotCWx3 ICAgICAgJDIsIDI4KCRzcCkKLQlzeXNjYWxsCi1fX2NwX2VuZDoKLQliZXEgICAgICQ3LCAkMCwg MWYKLQlhZGR1ICAgICRzcCwgJHNwLCAzMgotCXN1YnUgICAgJDIsICQwLCAkMgotMToJanIgICAg ICAkcmEKLQlub3AKLQotX19jcF9jYW5jZWw6Ci0JbW92ZSAgICAkMiwgJHJhCi0JYmFsICAgICAx ZgotCWFkZHUgICAgJHNwLCAkc3AsIDMyCi0JLmdwd29yZCAuCi0JLmdwd29yZCBfX2NhbmNlbAot MToJbHcgICAgICAkMywgKCRyYSkKLQlzdWJ1ICAgICQzLCAkcmEsICQzCi0JbHcgICAgICAkMjUs IDQoJHJhKQotCWFkZHUgICAgJDI1LCAkMjUsICQzCi0JanIgICAgICAkMjUKLQltb3ZlICAgICRy YSwgJDIKZGlmZiAtLWdpdCBhL3NyYy91bmlzdGQvbWlwcy9waXBlLnMgYi9zcmMvdW5pc3RkL21p cHMvcGlwZS5zCmluZGV4IGJhMmMzOWEuLmU2MDkxMmIgMTAwNjQ0Ci0tLSBhL3NyYy91bmlzdGQv bWlwcy9waXBlLnMKKysrIGIvc3JjL3VuaXN0ZC9taXBzL3BpcGUucwpAQCAtMTEsOCArMTEsOSBA QCBwaXBlOgogCWJlcSAkNywgJDAsIDFmCiAJbm9wCiAJbHcgJDI1LCAlY2FsbDE2KF9fc3lzY2Fs bF9yZXQpKCRncCkKLQlqciAkMjUKIAlzdWJ1ICQ0LCAkMCwgJDIKKwlqciAkMjUKKwlub3AKIDE6 CXN3ICQyLCAwKCQ0KQogCXN3ICQzLCA0KCQ0KQogCW1vdmUgJDIsICQwCg== --_004_BD7773622145634B952E5B54ACA8E349DAE2BD60PUMAIL01puimgte_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11212 Path: news.gmane.org!.POSTED!not-for-mail From: "dalias@libc.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Thu, 6 Apr 2017 12:18:04 -0400 Message-ID: <20170406161804.GM17319@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1491495500 9138 195.159.176.226 (6 Apr 2017 16:18:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Apr 2017 16:18:20 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11227-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 06 18:18:17 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cwA6v-0001nL-Qt for gllmg-musl@m.gmane.org; Thu, 06 Apr 2017 18:18:13 +0200 Original-Received: (qmail 9243 invoked by uid 550); 6 Apr 2017 16:18:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9225 invoked from network); 6 Apr 2017 16:18:16 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11212 Archived-At: On Wed, Apr 05, 2017 at 06:33:01AM +0000, Jaydeep Patil wrote: > Hi Rich, > > Please refer to > https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for > microMIPS32R2 O32 port. I have also attached the patch > (microMIPS32R2_v1_port.patch) for your reference. > Could you please review it? Some important first questions: Is micromips an ISA level or a new ISA? This is the same question as last time with MIPS r6 and the answer was not obvious and seemingly intentionally obscured by the official documentation. The answer is important to how we approach supporting it. Do cpus that support micromips also support plain mips? Is it like thumb where arm/thumb code can be linked together and call into one another in the same process, or are they different modes? Once we answer those questions, can you provide justifications for the proposed changes? From your patches it looks like branch delay slots don't exist in micromips mode. There may be other differences too; I didn't read it in detail. Rather than add a bunch of ifdefs I'd rather figure out how we can generalize the code so that it's compatible with both. This is what was done on arm when making it so the asm can be compiled as thumb2. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11218 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Fri, 7 Apr 2017 06:47:57 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1491547707 15295 195.159.176.226 (7 Apr 2017 06:48:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Apr 2017 06:48:27 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11233-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 07 08:48:22 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cwNgq-0002cY-OQ for gllmg-musl@m.gmane.org; Fri, 07 Apr 2017 08:48:12 +0200 Original-Received: (qmail 15412 invoked by uid 550); 7 Apr 2017 06:48: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: Original-Received: (qmail 15394 invoked from network); 7 Apr 2017 06:48:14 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkA= In-Reply-To: <20170406161804.GM17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11218 Archived-At: Hi Rich, microMIPS is an Application Specific Extension (ASE) to MIPS cores. Both mi= croMIPS and MIPS can co-exist. MIPS code can call microMIPS and vice-versa. microMIPS is a compressed ISA and contains both 16 and 32-bit instructions = for code size benefit.=20 microMIPS revision R2 to R5 contains branch instructions with delay slot, h= owever microMIPS revision R6 does not contain delay slots (B changed to BC)= .=20 Assembler converts a B+NOP to BC when assembled for R6. Thus we have remove= d non-NOP instructions from the delay slot so that same code can be used fo= r R6. Regards, Jaydeep >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of dalias@libc.org >Sent: 06 April 2017 PM 09:48 >To: musl@lists.openwall.com >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Wed, Apr 05, 2017 at 06:33:01AM +0000, Jaydeep Patil wrote: >> Hi Rich, >> >> Please refer to >> https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for >> microMIPS32R2 O32 port. I have also attached the patch >> (microMIPS32R2_v1_port.patch) for your reference. >> Could you please review it? > >Some important first questions: > >Is micromips an ISA level or a new ISA? This is the same question as last = time >with MIPS r6 and the answer was not obvious and seemingly intentionally >obscured by the official documentation. The answer is important to how we >approach supporting it. Do cpus that support micromips also support plain >mips? Is it like thumb where arm/thumb code can be linked together and cal= l >into one another in the same process, or are they different modes? > >Once we answer those questions, can you provide justifications for the >proposed changes? From your patches it looks like branch delay slots don't >exist in micromips mode. There may be other differences too; I didn't read= it >in detail. Rather than add a bunch of ifdefs I'd rather figure out how we = can >generalize the code so that it's compatible with both. This is what was do= ne on >arm when making it so the asm can be compiled as thumb2. > >Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11219 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Fri, 7 Apr 2017 10:19:41 -0400 Message-ID: <20170407141941.GQ17319@brightrain.aerifal.cx> References: <20170406161804.GM17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1491574805 5223 195.159.176.226 (7 Apr 2017 14:20:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Apr 2017 14:20:05 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11234-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 07 16:20:00 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cwUjw-000058-6e for gllmg-musl@m.gmane.org; Fri, 07 Apr 2017 16:19:52 +0200 Original-Received: (qmail 3683 invoked by uid 550); 7 Apr 2017 14:19:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3659 invoked from network); 7 Apr 2017 14:19:54 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11219 Archived-At: On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote: > Hi Rich, > > microMIPS is an Application Specific Extension (ASE) to MIPS cores. > Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS > and vice-versa. microMIPS is a compressed ISA and contains both 16 > and 32-bit instructions for code size benefit. In that case I'm confused what the benefit of compiling the asm files as micromips rather than plain mips is. Is it just to save 10 bytes here and there? Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11233 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Wed, 12 Apr 2017 11:54:10 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1491998069 24158 195.159.176.226 (12 Apr 2017 11:54:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Apr 2017 11:54:29 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11248-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 12 13:54:23 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyGqt-0006Bh-Fr for gllmg-musl@m.gmane.org; Wed, 12 Apr 2017 13:54:23 +0200 Original-Received: (qmail 7269 invoked by uid 550); 12 Apr 2017 11:54:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7248 invoked from network); 12 Apr 2017 11:54:25 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLg In-Reply-To: <20170407141941.GQ17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11233 Archived-At: Hi Rich, We can reuse existing MIPS code for microMIPS. There are places where we re= ad from $ra must be compiled for MIPS. Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 = for modifications. Thanks, Jaydeep >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 07 April 2017 PM 07:50 >To: musl@lists.openwall.com >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote: >> Hi Rich, >> >> microMIPS is an Application Specific Extension (ASE) to MIPS cores. >> Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS and >> vice-versa. microMIPS is a compressed ISA and contains both 16 and >> 32-bit instructions for code size benefit. > >In that case I'm confused what the benefit of compiling the asm files as >micromips rather than plain mips is. Is it just to save 10 bytes here and = there? > >Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11234 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Wed, 12 Apr 2017 21:25:35 +0200 Message-ID: <20170412192535.GG2082@port70.net> References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1492025151 6928 195.159.176.226 (12 Apr 2017 19:25:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Apr 2017 19:25:51 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: Jaydeep Patil To: musl@lists.openwall.com Original-X-From: musl-return-11249-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 12 21:25:47 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyNtg-0001hY-Pu for gllmg-musl@m.gmane.org; Wed, 12 Apr 2017 21:25:44 +0200 Original-Received: (qmail 21984 invoked by uid 550); 12 Apr 2017 19:25:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21966 invoked from network); 12 Apr 2017 19:25:47 -0000 Mail-Followup-To: musl@lists.openwall.com, Jaydeep Patil Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:11234 Archived-At: * Jaydeep Patil [2017-04-12 11:54:10 +0000]: > Hi Rich, > > We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS. > Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications. > is micromips a different encoding for mips instructions that works on some cpus but not others? does it require musl changes because micromips does not support all mips instructions just a subset? > Thanks, > Jaydeep > > >-----Original Message----- > >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > >Sent: 07 April 2017 PM 07:50 > >To: musl@lists.openwall.com > >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > > > >On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote: > >> Hi Rich, > >> > >> microMIPS is an Application Specific Extension (ASE) to MIPS cores. > >> Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS and > >> vice-versa. microMIPS is a compressed ISA and contains both 16 and > >> 32-bit instructions for code size benefit. > > > >In that case I'm confused what the benefit of compiling the asm files as > >micromips rather than plain mips is. Is it just to save 10 bytes here and there? > > > >Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11235 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Wed, 12 Apr 2017 16:27:21 -0400 Message-ID: <20170412202721.GY17319@brightrain.aerifal.cx> References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1492028854 10392 195.159.176.226 (12 Apr 2017 20:27:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Apr 2017 20:27:34 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jaydeep Patil To: musl@lists.openwall.com Original-X-From: musl-return-11250-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 12 22:27:30 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyOrR-0002Zp-JJ for gllmg-musl@m.gmane.org; Wed, 12 Apr 2017 22:27:29 +0200 Original-Received: (qmail 26526 invoked by uid 550); 12 Apr 2017 20:27:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26508 invoked from network); 12 Apr 2017 20:27:33 -0000 Content-Disposition: inline In-Reply-To: <20170412192535.GG2082@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11235 Archived-At: On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: > * Jaydeep Patil [2017-04-12 11:54:10 +0000]: > > Hi Rich, > > > > We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS. > > Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications. > > > > is micromips a different encoding for mips instructions > that works on some cpus but not others? Yes, it's something like thumb or thumb2 on arm, or the riscv compressed isa. What I'm not clear on is whether there are micromips-only cpu models that can't execute normal mips. If so we probably need the ability to build musl as micromips, but as long as cpus which support both support interworking (calls between the two type of code in the same process) reasonably, I don't think there's any reason to consider it a different subarch. If not (that is, if all cpus that support micromips also support the normal mips isa) then I fail to see why there's any need to compile musl's asm files as micromips. They're not size or performance bottlenecks. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11236 Path: news.gmane.org!.POSTED!not-for-mail From: Andre McCurdy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Wed, 12 Apr 2017 14:47:20 -0700 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492033654 17765 195.159.176.226 (12 Apr 2017 21:47:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Apr 2017 21:47:34 +0000 (UTC) Cc: Jaydeep Patil To: musl@lists.openwall.com Original-X-From: musl-return-11251-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 12 23:47:30 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyQ6r-0004Y2-Vu for gllmg-musl@m.gmane.org; Wed, 12 Apr 2017 23:47:30 +0200 Original-Received: (qmail 7876 invoked by uid 550); 12 Apr 2017 21:47:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7858 invoked from network); 12 Apr 2017 21:47:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LPaHm0WByQIobUWNbBdA42jGqP+HfmBYyIUXl4IY1Wc=; b=Eb6RIxdzqS8OTx/OnpjYk/uxurwSBZ3Tv6cyNMQzLjb4jufe8thLzwaF7m7UIYg87L ioX/yX+h7e6+o0MU18z5VeggWHHKr3XvrrPU17+4iBNvQyUQQbhWoEBDrTAxkd3nqA2X Rnpm91g8Fht+qEhtWAmVrh2I24sbPtwCQ4wr07rTrkP0pQtKC4ulFaqxlPVI37YMm7Rt 7DFaQ+CU8ydhtdHzIVE7WR8oSAAU2xJDNDWVm3V2ra99ayV2m1XK7jf0TIPrOvYJmCwm +ojL2y/bnwU5AWublKc2+jP0cmcQUrMUV7JPJF7kuooL3O2DVCKC4hoKLEn6EgSOhaTT LXcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LPaHm0WByQIobUWNbBdA42jGqP+HfmBYyIUXl4IY1Wc=; b=V3MC4QaE38rdOqF4dcQbg8o/Bmf7eDjSiEsWMaeco/w9j4Um0sK5Fx+1Fo5jgBeJqx uROTLebQpFVNnX09SRkpOI3Rmea3qr/acmvQLNtYhNf8N2hEocuneQn2TWiUS1Aw3+9X fXbVHK1PixIYMbAUQYuAyw7XyMalbupGf+i1iw6yUpVvSChgBOBvpjLSRXpZYcRwKQbv fJPkB4nhm6J8PFN1L/Ril3LzN1+4+tV9B796D8NdUMfNNgptT8IxHYmczgC0HUMoZUzr 1djsRTl43Pyk3EOPRFvDBCzQJrTUc7ggVtEs7mbLxURkou2QPwItpO2MRUtBX0u03oyy DOSQ== X-Gm-Message-State: AN3rC/650LtRv46VFqbLb7EcF2bmbr1LsENYFmf6Pe9axN19Xgkvwr+a h8BzleSBjZF2bZOeuB4hSeq///RyOLh7 X-Received: by 10.28.70.129 with SMTP id t123mr306779wma.98.1492033640902; Wed, 12 Apr 2017 14:47:20 -0700 (PDT) In-Reply-To: <20170412202721.GY17319@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11236 Archived-At: On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker wrote: > On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: >> * Jaydeep Patil [2017-04-12 11:54:10 +0000]: >> > Hi Rich, >> > >> > We can reuse existing MIPS code for microMIPS. There are places where = we read from $ra must be compiled for MIPS. >> > Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r= 2_v2 for modifications. >> > >> >> is micromips a different encoding for mips instructions >> that works on some cpus but not others? > > Yes, it's something like thumb or thumb2 on arm, or the riscv > compressed isa. What I'm not clear on is whether there are > micromips-only cpu models that can't execute normal mips. According to: https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/docum= entation/MIPS_Architecture_microMIPS32_InstructionSet_AFP_P_MD00582_06.04.p= df "microMIPS is also an alternative to the MIPS=C2=AE instruction encoding and can be implemented in parallel or stand-alone." "If only one ISA mode exists (either MIPS or microMIPS) then this mode switch mechanism does not exist" > If so we probably need the ability to build musl as micromips, but as > long as cpus which support both support interworking (calls between > the two type of code in the same process) reasonably, I don't think > there's any reason to consider it a different subarch. > > If not (that is, if all cpus that support micromips also support the > normal mips isa) then I fail to see why there's any need to compile > musl's asm files as micromips. They're not size or performance > bottlenecks. > > Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11237 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Thu, 13 Apr 2017 04:29:10 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Trace: blaine.gmane.org 1492057770 1904 195.159.176.226 (13 Apr 2017 04:29:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Apr 2017 04:29:30 +0000 (UTC) To: Andre McCurdy , "musl@lists.openwall.com" Original-X-From: musl-return-11252-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 13 06:29:25 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyWNo-0000KL-E8 for gllmg-musl@m.gmane.org; Thu, 13 Apr 2017 06:29:24 +0200 Original-Received: (qmail 32465 invoked by uid 550); 13 Apr 2017 04:29:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32440 invoked from network); 13 Apr 2017 04:29:27 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqA= In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11237 Archived-At: SGksDQoNCldpdGggdGhpcyBicmFuY2ggKG1pY3JvbWlwczMycjJfdjIpIHdlIGFyZSBzdXBwb3J0 aW5nIG1pY3JvTUlQUyBjb3JlcyB0aGF0IGNvLWV4aXN0IHdpdGggTUlQUy4gVGhlIE1VU0wgbGli cmFyeSBtdXN0IGJlIGJ1aWx0IHdpdGggLW1pbnRlcmxpbmstY29tcHJlc3NlZCBvcHRpb24gYXMg dGhlcmUgYXJlIGNvdXBsZSBvZiBoYW5kLXdyaXR0ZW4gTUlQUyBvbmx5IGZ1bmN0aW9ucy4gRm9y IG1pY3JvTUlQUyBvbmx5IGNvcmVzIHdlIHdpbGwgY3JlYXRlIGEgZGlmZmVyZW50IHN1YmFyY2gu DQoNClRoYW5rcywNCkpheWRlZXANCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogQW5kcmUgTWNDdXJkeSBbbWFpbHRvOmFybWNjdXJkeUBnbWFpbC5jb21dDQo+U2VudDogMTMg QXByaWwgMjAxNyBBTSAwMzoxNw0KPlRvOiBtdXNsQGxpc3RzLm9wZW53YWxsLmNvbQ0KPkNjOiBK YXlkZWVwIFBhdGlsDQo+U3ViamVjdDogUmU6IFttdXNsXSBbTVVTTF0gbWljcm9NSVBTMzJSMiBP MzIgcG9ydA0KPg0KPk9uIFdlZCwgQXByIDEyLCAyMDE3IGF0IDE6MjcgUE0sIFJpY2ggRmVsa2Vy IDxkYWxpYXNAbGliYy5vcmc+IHdyb3RlOg0KPj4gT24gV2VkLCBBcHIgMTIsIDIwMTcgYXQgMDk6 MjU6MzVQTSArMDIwMCwgU3phYm9sY3MgTmFneSB3cm90ZToNCj4+PiAqIEpheWRlZXAgUGF0aWwg PEpheWRlZXAuUGF0aWxAaW1ndGVjLmNvbT4gWzIwMTctMDQtMTIgMTE6NTQ6MTAgKzAwMDBdOg0K Pj4+ID4gSGkgUmljaCwNCj4+PiA+DQo+Pj4gPiBXZSBjYW4gcmV1c2UgZXhpc3RpbmcgTUlQUyBj b2RlIGZvciBtaWNyb01JUFMuIFRoZXJlIGFyZSBwbGFjZXMgd2hlcmUNCj53ZSByZWFkIGZyb20g JHJhIG11c3QgYmUgY29tcGlsZWQgZm9yIE1JUFMuDQo+Pj4gPiBQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly9naXRodWIuY29tL0pheWRlZXBJTUcvbXVzbC0NCj4xL3RyZWUvbWljcm9taXBzMzJyMl92 MiBmb3IgbW9kaWZpY2F0aW9ucy4NCj4+PiA+DQo+Pj4NCj4+PiBpcyBtaWNyb21pcHMgYSBkaWZm ZXJlbnQgZW5jb2RpbmcgZm9yIG1pcHMgaW5zdHJ1Y3Rpb25zIHRoYXQgd29ya3Mgb24NCj4+PiBz b21lIGNwdXMgYnV0IG5vdCBvdGhlcnM/DQo+Pg0KPj4gWWVzLCBpdCdzIHNvbWV0aGluZyBsaWtl IHRodW1iIG9yIHRodW1iMiBvbiBhcm0sIG9yIHRoZSByaXNjdg0KPj4gY29tcHJlc3NlZCBpc2Eu IFdoYXQgSSdtIG5vdCBjbGVhciBvbiBpcyB3aGV0aGVyIHRoZXJlIGFyZQ0KPj4gbWljcm9taXBz LW9ubHkgY3B1IG1vZGVscyB0aGF0IGNhbid0IGV4ZWN1dGUgbm9ybWFsIG1pcHMuDQo+DQo+QWNj b3JkaW5nIHRvOg0KPg0KPiAgaHR0cHM6Ly9pbWFnaW5hdGlvbi10ZWNobm9sb2dpZXMtY2xvdWRm cm9udC0NCj5hc3NldHMuczMuYW1hem9uYXdzLmNvbS9kb2N1bWVudGF0aW9uL01JUFNfQXJjaGl0 ZWN0dXJlX21pY3JvTUlQUzMyDQo+X0luc3RydWN0aW9uU2V0X0FGUF9QX01EMDA1ODJfMDYuMDQu cGRmDQo+DQo+Im1pY3JvTUlQUyBpcyBhbHNvIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBNSVBTwq4g aW5zdHJ1Y3Rpb24gZW5jb2RpbmcgYW5kIGNhbg0KPmJlIGltcGxlbWVudGVkIGluIHBhcmFsbGVs IG9yIHN0YW5kLWFsb25lLiINCj4NCj4iSWYgb25seSBvbmUgSVNBIG1vZGUgZXhpc3RzIChlaXRo ZXIgTUlQUyBvciBtaWNyb01JUFMpIHRoZW4gdGhpcyBtb2RlDQo+c3dpdGNoIG1lY2hhbmlzbSBk b2VzIG5vdCBleGlzdCINCj4NCj4+IElmIHNvIHdlIHByb2JhYmx5IG5lZWQgdGhlIGFiaWxpdHkg dG8gYnVpbGQgbXVzbCBhcyBtaWNyb21pcHMsIGJ1dCBhcw0KPj4gbG9uZyBhcyBjcHVzIHdoaWNo IHN1cHBvcnQgYm90aCBzdXBwb3J0IGludGVyd29ya2luZyAoY2FsbHMgYmV0d2Vlbg0KPj4gdGhl IHR3byB0eXBlIG9mIGNvZGUgaW4gdGhlIHNhbWUgcHJvY2VzcykgcmVhc29uYWJseSwgSSBkb24n dCB0aGluaw0KPj4gdGhlcmUncyBhbnkgcmVhc29uIHRvIGNvbnNpZGVyIGl0IGEgZGlmZmVyZW50 IHN1YmFyY2guDQo+Pg0KPj4gSWYgbm90ICh0aGF0IGlzLCBpZiBhbGwgY3B1cyB0aGF0IHN1cHBv cnQgbWljcm9taXBzIGFsc28gc3VwcG9ydCB0aGUNCj4+IG5vcm1hbCBtaXBzIGlzYSkgdGhlbiBJ IGZhaWwgdG8gc2VlIHdoeSB0aGVyZSdzIGFueSBuZWVkIHRvIGNvbXBpbGUNCj4+IG11c2wncyBh c20gZmlsZXMgYXMgbWljcm9taXBzLiBUaGV5J3JlIG5vdCBzaXplIG9yIHBlcmZvcm1hbmNlDQo+ PiBib3R0bGVuZWNrcy4NCj4+DQo+PiBSaWNoDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11238 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Thu, 13 Apr 2017 11:00:37 +0200 Message-ID: <20170413090036.GH2082@port70.net> References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492074060 5495 195.159.176.226 (13 Apr 2017 09:01:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Apr 2017 09:01:00 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: Andre McCurdy , Jaydeep Patil To: musl@lists.openwall.com Original-X-From: musl-return-11253-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 13 11:00:51 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyacU-000159-4c for gllmg-musl@m.gmane.org; Thu, 13 Apr 2017 11:00:50 +0200 Original-Received: (qmail 7319 invoked by uid 550); 13 Apr 2017 09:00:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7301 invoked from network); 13 Apr 2017 09:00:48 -0000 Mail-Followup-To: musl@lists.openwall.com, Andre McCurdy , Jaydeep Patil Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:11238 Archived-At: * Jaydeep Patil [2017-04-13 04:29:10 +0000]: > With this branch (micromips32r2_v2) we are supporting microMIPS cores tha= t co-exist with MIPS. The MUSL library must be built with -minterlink-compr= essed option as there are couple of hand-written MIPS only functions. For m= icroMIPS only cores we will create a different subarch. >=20 ok the _v2 branch makes sense to me (the patch is sufficiently small that you can send it to the list) i think i was looking at _v1 before > >-----Original Message----- > >From: Andre McCurdy [mailto:armccurdy@gmail.com] > >Sent: 13 April 2017 AM 03:17 > >To: musl@lists.openwall.com > >Cc: Jaydeep Patil > >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > > > >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker wrote: > >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: > >>> * Jaydeep Patil [2017-04-12 11:54:10 +0000= ]: > >>> > Hi Rich, > >>> > > >>> > We can reuse existing MIPS code for microMIPS. There are places whe= re > >we read from $ra must be compiled for MIPS. > >>> > Please refer to https://github.com/JaydeepIMG/musl- > >1/tree/micromips32r2_v2 for modifications. > >>> > > >>> > >>> is micromips a different encoding for mips instructions that works on > >>> some cpus but not others? > >> > >> Yes, it's something like thumb or thumb2 on arm, or the riscv > >> compressed isa. What I'm not clear on is whether there are > >> micromips-only cpu models that can't execute normal mips. > > > >According to: > > > > https://imagination-technologies-cloudfront- > >assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32 > >_InstructionSet_AFP_P_MD00582_06.04.pdf > > > >"microMIPS is also an alternative to the MIPS=AE instruction encoding an= d can > >be implemented in parallel or stand-alone." > > > >"If only one ISA mode exists (either MIPS or microMIPS) then this mode > >switch mechanism does not exist" > > > >> If so we probably need the ability to build musl as micromips, but as > >> long as cpus which support both support interworking (calls between > >> the two type of code in the same process) reasonably, I don't think > >> there's any reason to consider it a different subarch. > >> > >> If not (that is, if all cpus that support micromips also support the > >> normal mips isa) then I fail to see why there's any need to compile > >> musl's asm files as micromips. They're not size or performance > >> bottlenecks. > >> > >> Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11239 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Thu, 13 Apr 2017 10:37:05 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_002_BD7773622145634B952E5B54ACA8E349DAE2CAB5PUMAIL01puimgte_" X-Trace: blaine.gmane.org 1492079843 16926 195.159.176.226 (13 Apr 2017 10:37:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Apr 2017 10:37:23 +0000 (UTC) Cc: Andre McCurdy To: Szabolcs Nagy , "musl@lists.openwall.com" Original-X-From: musl-return-11254-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 13 12:37:19 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyc7r-0004JF-HM for gllmg-musl@m.gmane.org; Thu, 13 Apr 2017 12:37:19 +0200 Original-Received: (qmail 3481 invoked by uid 550); 13 Apr 2017 10:37:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3459 invoked from network); 13 Apr 2017 10:37:21 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXw In-Reply-To: <20170413090036.GH2082@port70.net> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11239 Archived-At: --_002_BD7773622145634B952E5B54ACA8E349DAE2CAB5PUMAIL01puimgte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Szabolcs, Please find the attached patch. Thanks, Jaydeep >-----Original Message----- >From: Szabolcs Nagy [mailto:nsz@port70.net] >Sent: 13 April 2017 PM 02:31 >To: musl@lists.openwall.com >Cc: Andre McCurdy; Jaydeep Patil >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >* Jaydeep Patil [2017-04-13 04:29:10 +0000]: >> With this branch (micromips32r2_v2) we are supporting microMIPS cores >that co-exist with MIPS. The MUSL library must be built with -minterlink- >compressed option as there are couple of hand-written MIPS only functions. >For microMIPS only cores we will create a different subarch. >> > >ok the _v2 branch makes sense to me >(the patch is sufficiently small that >you can send it to the list) > >i think i was looking at _v1 before > >> >-----Original Message----- >> >From: Andre McCurdy [mailto:armccurdy@gmail.com] >> >Sent: 13 April 2017 AM 03:17 >> >To: musl@lists.openwall.com >> >Cc: Jaydeep Patil >> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> > >> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker wrote: >> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: >> >>> * Jaydeep Patil [2017-04-12 11:54:10 >+0000]: >> >>> > Hi Rich, >> >>> > >> >>> > We can reuse existing MIPS code for microMIPS. There are places >> >>> > where >> >we read from $ra must be compiled for MIPS. >> >>> > Please refer to https://github.com/JaydeepIMG/musl- >> >1/tree/micromips32r2_v2 for modifications. >> >>> > >> >>> >> >>> is micromips a different encoding for mips instructions that works >> >>> on some cpus but not others? >> >> >> >> Yes, it's something like thumb or thumb2 on arm, or the riscv >> >> compressed isa. What I'm not clear on is whether there are >> >> micromips-only cpu models that can't execute normal mips. >> > >> >According to: >> > >> > https://imagination-technologies-cloudfront- >> >>assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS3 >2 >> >_InstructionSet_AFP_P_MD00582_06.04.pdf >> > >> >"microMIPS is also an alternative to the MIPS(r) instruction encoding >> >and can be implemented in parallel or stand-alone." >> > >> >"If only one ISA mode exists (either MIPS or microMIPS) then this >> >mode switch mechanism does not exist" >> > >> >> If so we probably need the ability to build musl as micromips, but >> >> as long as cpus which support both support interworking (calls >> >> between the two type of code in the same process) reasonably, I >> >> don't think there's any reason to consider it a different subarch. >> >> >> >> If not (that is, if all cpus that support micromips also support >> >> the normal mips isa) then I fail to see why there's any need to >> >> compile musl's asm files as micromips. They're not size or >> >> performance bottlenecks. >> >> >> >> Rich --_002_BD7773622145634B952E5B54ACA8E349DAE2CAB5PUMAIL01puimgte_ Content-Type: application/octet-stream; name="microMIPS_32R2_v2.patch" Content-Description: microMIPS_32R2_v2.patch Content-Disposition: attachment; filename="microMIPS_32R2_v2.patch"; size=1468; creation-date="Tue, 04 Apr 2017 07:11:32 GMT"; modification-date="Wed, 12 Apr 2017 10:16:33 GMT" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2FyY2gvbWlwcy9jcnRfYXJjaC5oIGIvYXJjaC9taXBzL2NydF9hcmNoLmgK aW5kZXggOWZjNTBkNy4uNzg4MzJiMCAxMDA2NDQKLS0tIGEvYXJjaC9taXBzL2NydF9hcmNoLmgK KysrIGIvYXJjaC9taXBzL2NydF9hcmNoLmgKQEAgLTEsNiArMSw3IEBACiBfX2FzbV9fKAogIi5z ZXQgcHVzaFxuIgogIi5zZXQgbm9yZW9yZGVyXG4iCisiLnNldCBub21pY3JvbWlwc1xuIgogIi50 ZXh0IFxuIgogIi5nbG9iYWwgXyIgU1RBUlQgIlxuIgogIi5nbG9iYWwgIiBTVEFSVCAiXG4iCmRp ZmYgLS1naXQgYS9hcmNoL21pcHMvcmVsb2MuaCBiL2FyY2gvbWlwcy9yZWxvYy5oCmluZGV4IGIz ZDU5YTQuLjc3MmIzYWEgMTAwNjQ0Ci0tLSBhL2FyY2gvbWlwcy9yZWxvYy5oCisrKyBiL2FyY2gv bWlwcy9yZWxvYy5oCkBAIC0zNiwxNSArMzYsMjMgQEAKICNkZWZpbmUgQ1JUSk1QKHBjLHNwKSBf X2FzbV9fIF9fdm9sYXRpbGVfXyggXAogCSJtb3ZlICRzcCwlMSA7IGpyICUwIiA6IDogInIiKHBj KSwgInIiKHNwKSA6ICJtZW1vcnkiICkKIAorLyoKKyAqIFdoZW4gY29tcGlsZWQgZm9yIG1pY3Jv TUlQUywgLmFsaWduIG1ha2VzIHN1cmUgdGhhdCAuZ3B3b3JkCisgKiBpcyBwbGFjZWQgYXQgd29y ZCBib3VuZGFyeS4gJHJhIG11c3QgcG9pbnQgdG8gZmlyc3QgLmdwd29yZC4KKyAqIElTQSBiaXQg b2YgJHJhIG11c3QgYmUgY2xlYXJlZCBmb3IgbWljcm9NSVBTIGJlZm9yZSB1c2luZyBpdAorICog YXMgYSBiYXNlIGFkZHJlc3MuIEZvciBNSVBTLCBJU0EgYml0IGlzIGFsd2F5cyB6ZXJvLgorKi8K ICNkZWZpbmUgR0VURlVOQ1NZTShmcCwgc3ltLCBnb3QpIF9fYXNtX18gKCBcCiAJIi5oaWRkZW4g IiAjc3ltICJcbiIgXAogCSIuc2V0IHB1c2ggXG4iIFwKIAkiLnNldCBub3Jlb3JkZXIgXG4iIFwK KwkiCS5hbGlnbiAyIFxuIiBcCiAJIgliYWwgMWYgXG4iIFwKIAkiCSBub3AgXG4iIFwKIAkiCS5n cHdvcmQgLiBcbiIgXAogCSIJLmdwd29yZCAiICNzeW0gIiBcbiIgXAotCSIxOglsdyAlMCwgKCRy YSkgXG4iIFwKKwkiMToJaW5zICRyYSwgJDAsIDAsIDEgXG4iIFwKKwkiCWx3ICUwLCAoJHJhKSBc biIgXAogCSIJc3VidSAlMCwgJHJhLCAlMCBcbiIgXAogCSIJbHcgJHJhLCA0KCRyYSkgXG4iIFwK IAkiCWFkZHUgJTAsICUwLCAkcmEgXG4iIFwKZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQvbWlwcy9z eXNjYWxsX2NwLnMgYi9zcmMvdGhyZWFkL21pcHMvc3lzY2FsbF9jcC5zCmluZGV4IGQyODQ2MjYu LjljNWY1NWUgMTAwNjQ0Ci0tLSBhL3NyYy90aHJlYWQvbWlwcy9zeXNjYWxsX2NwLnMKKysrIGIv c3JjL3RocmVhZC9taXBzL3N5c2NhbGxfY3AucwpAQCAtMSw1ICsxLDUgQEAKIC5zZXQgICAgbm9y ZW9yZGVyCi0KKy5zZXQgICAgbm9taWNyb21pcHMKIC5nbG9iYWwgX19jcF9iZWdpbgogLmhpZGRl biBfX2NwX2JlZ2luCiAudHlwZSAgIF9fY3BfYmVnaW4sQGZ1bmN0aW9uCg== --_002_BD7773622145634B952E5B54ACA8E349DAE2CAB5PUMAIL01puimgte_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11252 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Fri, 21 Apr 2017 09:40:45 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492767664 9697 195.159.176.226 (21 Apr 2017 09:41:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2017 09:41:04 +0000 (UTC) Cc: Andre McCurdy To: "musl@lists.openwall.com" , Szabolcs Nagy Original-X-From: musl-return-11267-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 21 11:41:00 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d1V3i-0002Oy-VL for gllmg-musl@m.gmane.org; Fri, 21 Apr 2017 11:40:59 +0200 Original-Received: (qmail 18173 invoked by uid 550); 21 Apr 2017 09:41:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18155 invoked from network); 21 Apr 2017 09:41:00 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXw//KPGKA= In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11252 Archived-At: Hi Szabolcs, Could you please commit this patch? Thanks, Jaydeep >-----Original Message----- >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >Sent: 13 April 2017 PM 04:07 >To: Szabolcs Nagy; musl@lists.openwall.com >Cc: Andre McCurdy >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >Hi Szabolcs, > >Please find the attached patch. > >Thanks, >Jaydeep > >>-----Original Message----- >>From: Szabolcs Nagy [mailto:nsz@port70.net] >>Sent: 13 April 2017 PM 02:31 >>To: musl@lists.openwall.com >>Cc: Andre McCurdy; Jaydeep Patil >>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> >>* Jaydeep Patil [2017-04-13 04:29:10 +0000]: >>> With this branch (micromips32r2_v2) we are supporting microMIPS cores >>that co-exist with MIPS. The MUSL library must be built with >>-minterlink- compressed option as there are couple of hand-written MIPS >only functions. >>For microMIPS only cores we will create a different subarch. >>> >> >>ok the _v2 branch makes sense to me >>(the patch is sufficiently small that >>you can send it to the list) >> >>i think i was looking at _v1 before >> >>> >-----Original Message----- >>> >From: Andre McCurdy [mailto:armccurdy@gmail.com] >>> >Sent: 13 April 2017 AM 03:17 >>> >To: musl@lists.openwall.com >>> >Cc: Jaydeep Patil >>> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >>> > >>> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker wrote: >>> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: >>> >>> * Jaydeep Patil [2017-04-12 11:54:10 >>+0000]: >>> >>> > Hi Rich, >>> >>> > >>> >>> > We can reuse existing MIPS code for microMIPS. There are places >>> >>> > where >>> >we read from $ra must be compiled for MIPS. >>> >>> > Please refer to https://github.com/JaydeepIMG/musl- >>> >1/tree/micromips32r2_v2 for modifications. >>> >>> > >>> >>> >>> >>> is micromips a different encoding for mips instructions that >>> >>> works on some cpus but not others? >>> >> >>> >> Yes, it's something like thumb or thumb2 on arm, or the riscv >>> >> compressed isa. What I'm not clear on is whether there are >>> >> micromips-only cpu models that can't execute normal mips. >>> > >>> >According to: >>> > >>> > https://imagination-technologies-cloudfront- >>> >>>assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS >3 >>2 >>> >_InstructionSet_AFP_P_MD00582_06.04.pdf >>> > >>> >"microMIPS is also an alternative to the MIPS(r) instruction >>> >encoding and can be implemented in parallel or stand-alone." >>> > >>> >"If only one ISA mode exists (either MIPS or microMIPS) then this >>> >mode switch mechanism does not exist" >>> > >>> >> If so we probably need the ability to build musl as micromips, but >>> >> as long as cpus which support both support interworking (calls >>> >> between the two type of code in the same process) reasonably, I >>> >> don't think there's any reason to consider it a different subarch. >>> >> >>> >> If not (that is, if all cpus that support micromips also support >>> >> the normal mips isa) then I fail to see why there's any need to >>> >> compile musl's asm files as micromips. They're not size or >>> >> performance bottlenecks. >>> >> >>> >> Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11255 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Fri, 21 Apr 2017 09:26:50 -0400 Message-ID: <20170421132650.GD17319@brightrain.aerifal.cx> References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1492781227 16029 195.159.176.226 (21 Apr 2017 13:27:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2017 13:27:07 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andre McCurdy , "musl@lists.openwall.com" To: Jaydeep Patil Original-X-From: musl-return-11270-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 21 15:27:02 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d1YaT-00041U-MM for gllmg-musl@m.gmane.org; Fri, 21 Apr 2017 15:27:01 +0200 Original-Received: (qmail 20086 invoked by uid 550); 21 Apr 2017 13:27:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20046 invoked from network); 21 Apr 2017 13:27:04 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11255 Archived-At: On Thu, Apr 13, 2017 at 04:29:10AM +0000, Jaydeep Patil wrote: > Hi, > > With this branch (micromips32r2_v2) we are supporting microMIPS > cores that co-exist with MIPS. The MUSL library must be built with > -minterlink-compressed option as there are couple of hand-written > MIPS only functions. For microMIPS only cores we will create a > different subarch. I don't think there's any indication yet that a different subarch is appropriate for micromips-only cores. This would only be the case if they are somehow ABI-incompatible with normal mips. If it would be possible to run binaries that were built for micromips only on a cpu core that supports both, using a libc.so that was built either for plain mips or micromips or a mix, then for our purposes it's the same arch, just a different ISA level/profile. Rich > >-----Original Message----- > >From: Andre McCurdy [mailto:armccurdy@gmail.com] > >Sent: 13 April 2017 AM 03:17 > >To: musl@lists.openwall.com > >Cc: Jaydeep Patil > >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > > > >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker wrote: > >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote: > >>> * Jaydeep Patil [2017-04-12 11:54:10 +0000]: > >>> > Hi Rich, > >>> > > >>> > We can reuse existing MIPS code for microMIPS. There are places where > >we read from $ra must be compiled for MIPS. > >>> > Please refer to https://github.com/JaydeepIMG/musl- > >1/tree/micromips32r2_v2 for modifications. > >>> > > >>> > >>> is micromips a different encoding for mips instructions that works on > >>> some cpus but not others? > >> > >> Yes, it's something like thumb or thumb2 on arm, or the riscv > >> compressed isa. What I'm not clear on is whether there are > >> micromips-only cpu models that can't execute normal mips. > > > >According to: > > > > https://imagination-technologies-cloudfront- > >assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32 > >_InstructionSet_AFP_P_MD00582_06.04.pdf > > > >"microMIPS is also an alternative to the MIPS® instruction encoding and can > >be implemented in parallel or stand-alone." > > > >"If only one ISA mode exists (either MIPS or microMIPS) then this mode > >switch mechanism does not exist" > > > >> If so we probably need the ability to build musl as micromips, but as > >> long as cpus which support both support interworking (calls between > >> the two type of code in the same process) reasonably, I don't think > >> there's any reason to consider it a different subarch. > >> > >> If not (that is, if all cpus that support micromips also support the > >> normal mips isa) then I fail to see why there's any need to compile > >> musl's asm files as micromips. They're not size or performance > >> bottlenecks. > >> > >> Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11256 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Fri, 21 Apr 2017 09:33:00 -0400 Message-ID: <20170421133300.GE17319@brightrain.aerifal.cx> References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1492781597 14487 195.159.176.226 (21 Apr 2017 13:33:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2017 13:33:17 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Jaydeep Patil Original-X-From: musl-return-11271-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 21 15:33:12 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d1YgS-0003e5-La for gllmg-musl@m.gmane.org; Fri, 21 Apr 2017 15:33:12 +0200 Original-Received: (qmail 24365 invoked by uid 550); 21 Apr 2017 13:33:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24346 invoked from network); 21 Apr 2017 13:33:16 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11256 Archived-At: On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote: > Hi Szabolcs, > > Please find the attached patch. I still don't follow the motivation of all the changes in this patch. See comments below: > [...] > diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h > index 9fc50d7..78832b0 100644 > --- a/arch/mips/crt_arch.h > +++ b/arch/mips/crt_arch.h > @@ -1,6 +1,7 @@ > __asm__( > ".set push\n" > ".set noreorder\n" > +".set nomicromips\n" > ".text \n" > ".global _" START "\n" > ".global " START "\n" Is there a need for crt1.o (or other users of this file like dlstart/rcrt1) to be built as plain mips rather than micromips? If so, please explain. Arbitrary changes like this without an explanation of why they're being made (what was broken before, and why this is the correct fix) are not acceptable. > diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h > index b3d59a4..772b3aa 100644 > --- a/arch/mips/reloc.h > +++ b/arch/mips/reloc.h > @@ -36,15 +36,23 @@ > #define CRTJMP(pc,sp) __asm__ __volatile__( \ > "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" ) > > +/* > + * When compiled for microMIPS, .align makes sure that .gpword > + * is placed at word boundary. $ra must point to first .gpword. > + * ISA bit of $ra must be cleared for microMIPS before using it > + * as a base address. For MIPS, ISA bit is always zero. > +*/ > #define GETFUNCSYM(fp, sym, got) __asm__ ( \ > ".hidden " #sym "\n" \ > ".set push \n" \ > ".set noreorder \n" \ > + " .align 2 \n" \ > " bal 1f \n" \ > " nop \n" \ > " .gpword . \n" \ > " .gpword " #sym " \n" \ > - "1: lw %0, ($ra) \n" \ > + "1: ins $ra, $0, 0, 1 \n" \ > + " lw %0, ($ra) \n" \ > " subu %0, $ra, %0 \n" \ > " lw $ra, 4($ra) \n" \ > " addu %0, %0, $ra \n" \ By this, do you mean that .gpword is producing a value that's relative to the actual byte position of the directive rather than the logical (ISA bit set) value of "." at the point of .gpword? > diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s > index d284626..9c5f55e 100644 > --- a/src/thread/mips/syscall_cp.s > +++ b/src/thread/mips/syscall_cp.s > @@ -1,5 +1,5 @@ > .set noreorder > - > +.set nomicromips > .global __cp_begin > .hidden __cp_begin > .type __cp_begin,@function I'm also unclear on the motivation of this one. Before (v1) you had a lot of changes to replace .s files with something micromips-compatible (removing branch delay slots); now (v2) those changes are not included. So are .s files even being built as micromips at all? If not, why is the above needed? If so, how do the files with delay slots work? Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11278 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Mon, 24 Apr 2017 05:30:34 +0000 Message-ID: References: <20170406161804.GM17319@brightrain.aerifal.cx> <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1493011856 5293 195.159.176.226 (24 Apr 2017 05:30:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2017 05:30:56 +0000 (UTC) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Rich Felker Original-X-From: musl-return-11293-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 24 07:30:48 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d2WaF-0001BP-RO for gllmg-musl@m.gmane.org; Mon, 24 Apr 2017 07:30:47 +0200 Original-Received: (qmail 15729 invoked by uid 550); 24 Apr 2017 05:30:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15711 invoked from network); 24 Apr 2017 05:30:51 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24A== In-Reply-To: <20170421133300.GE17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11278 Archived-At: >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 21 April 2017 PM 07:03 >To: Jaydeep Patil >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote: >> Hi Szabolcs, >> >> Please find the attached patch. > >I still don't follow the motivation of all the changes in this patch. >See comments below: > >> [...] >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index >> 9fc50d7..78832b0 100644 >> --- a/arch/mips/crt_arch.h >> +++ b/arch/mips/crt_arch.h >> @@ -1,6 +1,7 @@ >> __asm__( >> ".set push\n" >> ".set noreorder\n" >> +".set nomicromips\n" >> ".text \n" >> ".global _" START "\n" >> ".global " START "\n" > >Is there a need for crt1.o (or other users of this file like >dlstart/rcrt1) to be built as plain mips rather than micromips? If so, ple= ase >explain. Arbitrary changes like this without an explanation of why they're >being made (what was broken before, and why this is the correct fix) are n= ot >acceptable. The crt1.o and __cp_begin are built as pure MIPS functions rather than micr= oMIPS as they are reading data using $ra register (with ISA bit set). We can clear the ISA bit (using INS) and choose to compile these functions = as microMIPS. >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index >> b3d59a4..772b3aa 100644 >> --- a/arch/mips/reloc.h >> +++ b/arch/mips/reloc.h >> @@ -36,15 +36,23 @@ >> #define CRTJMP(pc,sp) __asm__ __volatile__( \ >> "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" ) >> >> +/* >> + * When compiled for microMIPS, .align makes sure that .gpword >> + * is placed at word boundary. $ra must point to first .gpword. >> + * ISA bit of $ra must be cleared for microMIPS before using it >> + * as a base address. For MIPS, ISA bit is always zero. >> +*/ >> #define GETFUNCSYM(fp, sym, got) __asm__ ( \ >> ".hidden " #sym "\n" \ >> ".set push \n" \ >> ".set noreorder \n" \ >> + " .align 2 \n" \ >> " bal 1f \n" \ >> " nop \n" \ >> " .gpword . \n" \ >> " .gpword " #sym " \n" \ >> - "1: lw %0, ($ra) \n" \ >> + "1: ins $ra, $0, 0, 1 \n" \ >> + " lw %0, ($ra) \n" \ >> " subu %0, $ra, %0 \n" \ >> " lw $ra, 4($ra) \n" \ >> " addu %0, %0, $ra \n" \ > >By this, do you mean that .gpword is producing a value that's relative to = the >actual byte position of the directive rather than the logical (ISA bit set= ) value >of "." at the point of .gpword? ISA bit is set for all microMIPS symbols (including the dot symbol). The GE= TFUNCSYM macro cannot be compiled as pure MIPS code as it might be expanded= in a microMIPS function. We need to clear the ISA bit of $ra before using it as a base address in lo= ad/store instructions. >> diff --git a/src/thread/mips/syscall_cp.s >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >> --- a/src/thread/mips/syscall_cp.s >> +++ b/src/thread/mips/syscall_cp.s >> @@ -1,5 +1,5 @@ >> .set noreorder >> - >> +.set nomicromips >> .global __cp_begin >> .hidden __cp_begin >> .type __cp_begin,@function > >I'm also unclear on the motivation of this one. Before (v1) you had a lot = of >changes to replace .s files with something micromips-compatible (removing >branch delay slots); now (v2) those changes are not included. So are .s fi= les >even being built as micromips at all? If not, why is the above needed? If = so, >how do the files with delay slots work? Branch delay slots are removed (called as compact instructions) in the newe= r MIPS/microMIPS cores (in development).=20 The MIPS/microMIPS R2-R6 still support instructions with delay slot. Assembler takes care of converting a BRANCH + NOP to its appropriate compac= t instruction (BEQ + NOP to BEQC).=20 With the v1 branch I was trying to create generic hand-written assembly whi= ch can be used for newer cores with the compact instructions. However I realized that it would appropriate to create a new arch instead o= f creating generic assembly. Thus in v2 branch I modified only those functions which would create issues= when compiled with interlinking on. >Rich Thanks, Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11281 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Mon, 24 Apr 2017 09:48:08 -0400 Message-ID: <20170424134808.GQ17319@brightrain.aerifal.cx> References: <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1493041708 18757 195.159.176.226 (24 Apr 2017 13:48:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2017 13:48:28 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Jaydeep Patil Original-X-From: musl-return-11296-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 24 15:48:24 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d2eLn-0004kA-5F for gllmg-musl@m.gmane.org; Mon, 24 Apr 2017 15:48:23 +0200 Original-Received: (qmail 16163 invoked by uid 550); 24 Apr 2017 13:48:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16142 invoked from network); 24 Apr 2017 13:48:26 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11281 Archived-At: On Mon, Apr 24, 2017 at 05:30:34AM +0000, Jaydeep Patil wrote: > >-----Original Message----- > >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > >Sent: 21 April 2017 PM 07:03 > >To: Jaydeep Patil > >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy > >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > > > >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote: > >> Hi Szabolcs, > >> > >> Please find the attached patch. > > > >I still don't follow the motivation of all the changes in this patch. > >See comments below: > > > >> [...] > >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index > >> 9fc50d7..78832b0 100644 > >> --- a/arch/mips/crt_arch.h > >> +++ b/arch/mips/crt_arch.h > >> @@ -1,6 +1,7 @@ > >> __asm__( > >> ".set push\n" > >> ".set noreorder\n" > >> +".set nomicromips\n" > >> ".text \n" > >> ".global _" START "\n" > >> ".global " START "\n" > > > >Is there a need for crt1.o (or other users of this file like > >dlstart/rcrt1) to be built as plain mips rather than micromips? If so, please > >explain. Arbitrary changes like this without an explanation of why they're > >being made (what was broken before, and why this is the correct fix) are not > >acceptable. > > The crt1.o and __cp_begin are built as pure MIPS functions rather > than microMIPS as they are reading data using $ra register (with ISA > bit set). We can clear the ISA bit (using INS) and choose to compile > these functions as microMIPS. I see. So all the .s files are assembled as plain (32-bit) MIPS, and these files are just affected because the asm is included in .c files that might be compiled in microMIPS mode. That makes sense. I think it's probably just better to make the code microMIPS-compatible though by clearing the low bits. But syscall_cp.s needs some care because saved instruction pointer values are compared against these labels. In micromips mode, do the labels evaluate with the +1 low bit offset? > >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index > >> b3d59a4..772b3aa 100644 > >> --- a/arch/mips/reloc.h > >> +++ b/arch/mips/reloc.h > >> @@ -36,15 +36,23 @@ > >> #define CRTJMP(pc,sp) __asm__ __volatile__( \ > >> "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" ) > >> > >> +/* > >> + * When compiled for microMIPS, .align makes sure that .gpword > >> + * is placed at word boundary. $ra must point to first .gpword. > >> + * ISA bit of $ra must be cleared for microMIPS before using it > >> + * as a base address. For MIPS, ISA bit is always zero. > >> +*/ > >> #define GETFUNCSYM(fp, sym, got) __asm__ ( \ > >> ".hidden " #sym "\n" \ > >> ".set push \n" \ > >> ".set noreorder \n" \ > >> + " .align 2 \n" \ > >> " bal 1f \n" \ > >> " nop \n" \ > >> " .gpword . \n" \ > >> " .gpword " #sym " \n" \ > >> - "1: lw %0, ($ra) \n" \ > >> + "1: ins $ra, $0, 0, 1 \n" \ > >> + " lw %0, ($ra) \n" \ > >> " subu %0, $ra, %0 \n" \ > >> " lw $ra, 4($ra) \n" \ > >> " addu %0, %0, $ra \n" \ > > > >By this, do you mean that .gpword is producing a value that's relative to the > >actual byte position of the directive rather than the logical (ISA bit set) value > >of "." at the point of .gpword? > > ISA bit is set for all microMIPS symbols (including the dot symbol). > The GETFUNCSYM macro cannot be compiled as pure MIPS code as it > might be expanded in a microMIPS function. We need to clear the ISA > bit of $ra before using it as a base address in load/store > instructions. OK. And the same appproach would work for crt_arch.h and other places, right? > >> diff --git a/src/thread/mips/syscall_cp.s > >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 > >> --- a/src/thread/mips/syscall_cp.s > >> +++ b/src/thread/mips/syscall_cp.s > >> @@ -1,5 +1,5 @@ > >> .set noreorder > >> - > >> +.set nomicromips > >> .global __cp_begin > >> .hidden __cp_begin > >> .type __cp_begin,@function > > > >I'm also unclear on the motivation of this one. Before (v1) you had a lot of > >changes to replace .s files with something micromips-compatible (removing > >branch delay slots); now (v2) those changes are not included. So are .s files > >even being built as micromips at all? If not, why is the above needed? If so, > >how do the files with delay slots work? > > Branch delay slots are removed (called as compact instructions) in > the newer MIPS/microMIPS cores (in development). > The MIPS/microMIPS R2-R6 still support instructions with delay slot. > Assembler takes care of converting a BRANCH + NOP to its appropriate > compact instruction (BEQ + NOP to BEQC). > With the v1 branch I was trying to create generic hand-written > assembly which can be used for newer cores with the compact > instructions. > However I realized that it would appropriate to create a new arch > instead of creating generic assembly. > Thus in v2 branch I modified only those functions which would create > issues when compiled with interlinking on. Based on the discussions so far, I don't think pure-micromips qualifies as a new arch. If it would be possible to take a program compiled as micromips-only, and run it with the libc.so/ldso built for plain mips on a machine that supports both forms of code, then it's not a separate arch, and as I understand it this should be possible. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11287 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Tue, 25 Apr 2017 04:45:29 +0000 Message-ID: References: <20170407141941.GQ17319@brightrain.aerifal.cx> <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1493095549 24631 195.159.176.226 (25 Apr 2017 04:45:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 04:45:49 +0000 (UTC) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Rich Felker Original-X-From: musl-return-11302-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 25 06:45:44 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d2sMA-0006FP-8h for gllmg-musl@m.gmane.org; Tue, 25 Apr 2017 06:45:42 +0200 Original-Received: (qmail 11927 invoked by uid 550); 25 Apr 2017 04:45:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11906 invoked from network); 25 Apr 2017 04:45:45 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8A= In-Reply-To: <20170424134808.GQ17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11287 Archived-At: >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 24 April 2017 PM 07:18 >To: Jaydeep Patil >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Mon, Apr 24, 2017 at 05:30:34AM +0000, Jaydeep Patil wrote: >> >-----Original Message----- >> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >> >Sent: 21 April 2017 PM 07:03 >> >To: Jaydeep Patil >> >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> > >> >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote: >> >> Hi Szabolcs, >> >> >> >> Please find the attached patch. >> > >> >I still don't follow the motivation of all the changes in this patch. >> >See comments below: >> > >> >> [...] >> >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index >> >> 9fc50d7..78832b0 100644 >> >> --- a/arch/mips/crt_arch.h >> >> +++ b/arch/mips/crt_arch.h >> >> @@ -1,6 +1,7 @@ >> >> __asm__( >> >> ".set push\n" >> >> ".set noreorder\n" >> >> +".set nomicromips\n" >> >> ".text \n" >> >> ".global _" START "\n" >> >> ".global " START "\n" >> > >> >Is there a need for crt1.o (or other users of this file like >> >dlstart/rcrt1) to be built as plain mips rather than micromips? If >> >so, please explain. Arbitrary changes like this without an >> >explanation of why they're being made (what was broken before, and >> >why this is the correct fix) are not acceptable. >> >> The crt1.o and __cp_begin are built as pure MIPS functions rather than >> microMIPS as they are reading data using $ra register (with ISA bit >> set). We can clear the ISA bit (using INS) and choose to compile these >> functions as microMIPS. > >I see. So all the .s files are assembled as plain (32-bit) MIPS, and these= files are >just affected because the asm is included in .c files that might be compil= ed in >microMIPS mode. That makes sense. I think it's probably just better to mak= e >the code microMIPS-compatible though by clearing the low bits.=20 Ok, I will remove the "nomicromips" restriction and clear the ISA bit inst= ead. > But syscall_cp.s needs some care because saved instruction pointer values= are >compared against these labels. In micromips mode, do the labels evaluate >with the +1 low bit offset? Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However I don'= t see any issue with following comparison pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end The ISA bit will be set even for PC in the saved context. >> >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index >> >> b3d59a4..772b3aa 100644 >> >> --- a/arch/mips/reloc.h >> >> +++ b/arch/mips/reloc.h >> >> @@ -36,15 +36,23 @@ >> >> #define CRTJMP(pc,sp) __asm__ __volatile__( \ >> >> "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" ) >> >> >> >> +/* >> >> + * When compiled for microMIPS, .align makes sure that .gpword >> >> + * is placed at word boundary. $ra must point to first .gpword. >> >> + * ISA bit of $ra must be cleared for microMIPS before using it >> >> + * as a base address. For MIPS, ISA bit is always zero. >> >> +*/ >> >> #define GETFUNCSYM(fp, sym, got) __asm__ ( \ >> >> ".hidden " #sym "\n" \ >> >> ".set push \n" \ >> >> ".set noreorder \n" \ >> >> + " .align 2 \n" \ >> >> " bal 1f \n" \ >> >> " nop \n" \ >> >> " .gpword . \n" \ >> >> " .gpword " #sym " \n" \ >> >> - "1: lw %0, ($ra) \n" \ >> >> + "1: ins $ra, $0, 0, 1 \n" \ >> >> + " lw %0, ($ra) \n" \ >> >> " subu %0, $ra, %0 \n" \ >> >> " lw $ra, 4($ra) \n" \ >> >> " addu %0, %0, $ra \n" \ >> > >> >By this, do you mean that .gpword is producing a value that's >> >relative to the actual byte position of the directive rather than the >> >logical (ISA bit set) value of "." at the point of .gpword? >> >> ISA bit is set for all microMIPS symbols (including the dot symbol). >> The GETFUNCSYM macro cannot be compiled as pure MIPS code as it might >> be expanded in a microMIPS function. We need to clear the ISA bit of >> $ra before using it as a base address in load/store instructions. > >OK. And the same appproach would work for crt_arch.h and other places, >right? Yes. >> >> diff --git a/src/thread/mips/syscall_cp.s >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >> >> --- a/src/thread/mips/syscall_cp.s >> >> +++ b/src/thread/mips/syscall_cp.s >> >> @@ -1,5 +1,5 @@ >> >> .set noreorder >> >> - >> >> +.set nomicromips >> >> .global __cp_begin >> >> .hidden __cp_begin >> >> .type __cp_begin,@function >> > >> >I'm also unclear on the motivation of this one. Before (v1) you had a >> >lot of changes to replace .s files with something >> >micromips-compatible (removing branch delay slots); now (v2) those >> >changes are not included. So are .s files even being built as >> >micromips at all? If not, why is the above needed? If so, how do the fi= les >with delay slots work? >> >> Branch delay slots are removed (called as compact instructions) in the >> newer MIPS/microMIPS cores (in development). >> The MIPS/microMIPS R2-R6 still support instructions with delay slot. >> Assembler takes care of converting a BRANCH + NOP to its appropriate >> compact instruction (BEQ + NOP to BEQC). >> With the v1 branch I was trying to create generic hand-written >> assembly which can be used for newer cores with the compact >> instructions. >> However I realized that it would appropriate to create a new arch >> instead of creating generic assembly. >> Thus in v2 branch I modified only those functions which would create >> issues when compiled with interlinking on. > >Based on the discussions so far, I don't think pure-micromips qualifies as= a >new arch. If it would be possible to take a program compiled as micromips- >only, and run it with the libc.so/ldso built for plain mips on a machine t= hat >supports both forms of code, then it's not a separate arch, and as I >understand it this should be possible. Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch. >Rich I will create v3 if you are OK with this approach. Thanks, Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11294 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Tue, 25 Apr 2017 12:52:45 -0400 Message-ID: <20170425165245.GW17319@brightrain.aerifal.cx> References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1493139187 24925 195.159.176.226 (25 Apr 2017 16:53:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 16:53:07 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Jaydeep Patil Original-X-From: musl-return-11309-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 25 18:53:02 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d33i1-0006Kx-Fz for gllmg-musl@m.gmane.org; Tue, 25 Apr 2017 18:53:01 +0200 Original-Received: (qmail 13738 invoked by uid 550); 25 Apr 2017 16:53:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13712 invoked from network); 25 Apr 2017 16:53:03 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11294 Archived-At: On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: > > But syscall_cp.s needs some care because saved instruction pointer values are > >compared against these labels. In micromips mode, do the labels evaluate > >with the +1 low bit offset? > > Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However > I don't see any issue with following comparison > > pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end > > The ISA bit will be set even for PC in the saved context. Agreed, I think it should work as expected. > >> >> diff --git a/src/thread/mips/syscall_cp.s > >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 > >> >> --- a/src/thread/mips/syscall_cp.s > >> >> +++ b/src/thread/mips/syscall_cp.s > >> >> @@ -1,5 +1,5 @@ > >> >> .set noreorder > >> >> - > >> >> +.set nomicromips > >> >> .global __cp_begin > >> >> .hidden __cp_begin > >> >> .type __cp_begin,@function > >> > > >> >I'm also unclear on the motivation of this one. Before (v1) you had a > >> >lot of changes to replace .s files with something > >> >micromips-compatible (removing branch delay slots); now (v2) those > >> >changes are not included. So are .s files even being built as > >> >micromips at all? If not, why is the above needed? If so, how do the files > >with delay slots work? > >> > >> Branch delay slots are removed (called as compact instructions) in the > >> newer MIPS/microMIPS cores (in development). > >> The MIPS/microMIPS R2-R6 still support instructions with delay slot. > >> Assembler takes care of converting a BRANCH + NOP to its appropriate > >> compact instruction (BEQ + NOP to BEQC). > >> With the v1 branch I was trying to create generic hand-written > >> assembly which can be used for newer cores with the compact > >> instructions. > >> However I realized that it would appropriate to create a new arch > >> instead of creating generic assembly. > >> Thus in v2 branch I modified only those functions which would create > >> issues when compiled with interlinking on. > > > >Based on the discussions so far, I don't think pure-micromips qualifies as a > >new arch. If it would be possible to take a program compiled as micromips- > >only, and run it with the libc.so/ldso built for plain mips on a machine that > >supports both forms of code, then it's not a separate arch, and as I > >understand it this should be possible. > > Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch. > > >Rich > > I will create v3 if you are OK with this approach. OK. Can you factor it as one patch that's the minimal needed to make the .c files (including ones that include the crt_arch.h/reloc.h asm code) build correctly in micromips mode, which should be quick to review/accept, and a second (if you want to do this phase now; if not you can leave it til later) that makes the .s files micromips-compatible? Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11304 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Wed, 26 Apr 2017 07:14:06 +0000 Message-ID: References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_002_BD7773622145634B952E5B54ACA8E349DAE2DC38PUMAIL01puimgte_" X-Trace: blaine.gmane.org 1493190880 9851 195.159.176.226 (26 Apr 2017 07:14:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Apr 2017 07:14:40 +0000 (UTC) Cc: Szabolcs Nagy , "musl@lists.openwall.com" , Andre McCurdy To: Rich Felker Original-X-From: musl-return-11319-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 26 09:14:28 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d3H9Z-0002Ce-3U for gllmg-musl@m.gmane.org; Wed, 26 Apr 2017 09:14:21 +0200 Original-Received: (qmail 16270 invoked by uid 550); 26 Apr 2017 07:14:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16252 invoked from network); 26 Apr 2017 07:14:23 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ In-Reply-To: <20170425165245.GW17319@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:11304 Archived-At: --_002_BD7773622145634B952E5B54ACA8E349DAE2DC38PUMAIL01puimgte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 25 April 2017 PM 10:23 >To: Jaydeep Patil >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >> > But syscall_cp.s needs some care because saved instruction pointer >> >values are compared against these labels. In micromips mode, do the >> >labels evaluate with the +1 low bit offset? >> >> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However I >> don't see any issue with following comparison >> >> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >> >> The ISA bit will be set even for PC in the saved context. > >Agreed, I think it should work as expected. > >> >> >> diff --git a/src/thread/mips/syscall_cp.s >> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >> >> >> --- a/src/thread/mips/syscall_cp.s >> >> >> +++ b/src/thread/mips/syscall_cp.s >> >> >> @@ -1,5 +1,5 @@ >> >> >> .set noreorder >> >> >> - >> >> >> +.set nomicromips >> >> >> .global __cp_begin >> >> >> .hidden __cp_begin >> >> >> .type __cp_begin,@function >> >> > >> >> >I'm also unclear on the motivation of this one. Before (v1) you >> >> >had a lot of changes to replace .s files with something >> >> >micromips-compatible (removing branch delay slots); now (v2) those >> >> >changes are not included. So are .s files even being built as >> >> >micromips at all? If not, why is the above needed? If so, how do >> >> >the files >> >with delay slots work? >> >> >> >> Branch delay slots are removed (called as compact instructions) in >> >> the newer MIPS/microMIPS cores (in development). >> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot. >> >> Assembler takes care of converting a BRANCH + NOP to its >> >> appropriate compact instruction (BEQ + NOP to BEQC). >> >> With the v1 branch I was trying to create generic hand-written >> >> assembly which can be used for newer cores with the compact >> >> instructions. >> >> However I realized that it would appropriate to create a new arch >> >> instead of creating generic assembly. >> >> Thus in v2 branch I modified only those functions which would >> >> create issues when compiled with interlinking on. >> > >> >Based on the discussions so far, I don't think pure-micromips >> >qualifies as a new arch. If it would be possible to take a program >> >compiled as micromips- only, and run it with the libc.so/ldso built >> >for plain mips on a machine that supports both forms of code, then >> >it's not a separate arch, and as I understand it this should be possibl= e. >> >> Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch= . >> >> >Rich >> >> I will create v3 if you are OK with this approach. > >OK. Can you factor it as one patch that's the minimal needed to make the .= c >files (including ones that include the crt_arch.h/reloc.h asm >code) build correctly in micromips mode, which should be quick to >review/accept, and a second (if you want to do this phase now; if not you = can >leave it til later) that makes the .s files micromips-compatible? Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 = for changes (also attached as a patch).=20 I will push a separate patch to make .s file microMIPS-only compatible. >Rich Thanks, Jaydeep --_002_BD7773622145634B952E5B54ACA8E349DAE2DC38PUMAIL01puimgte_ Content-Type: application/octet-stream; name="microMIPS_32R2_v3.patch" Content-Description: microMIPS_32R2_v3.patch Content-Disposition: attachment; filename="microMIPS_32R2_v3.patch"; size=1866; creation-date="Wed, 26 Apr 2017 07:12:12 GMT"; modification-date="Wed, 26 Apr 2017 07:12:12 GMT" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2FyY2gvbWlwcy9jcnRfYXJjaC5oIGIvYXJjaC9taXBzL2NydF9hcmNoLmgK aW5kZXggOWZjNTBkNy4uYTdiYTBlNiAxMDA2NDQKLS0tIGEvYXJjaC9taXBzL2NydF9hcmNoLmgK KysrIGIvYXJjaC9taXBzL2NydF9hcmNoLmgKQEAgLTgsNiArOCw3IEBAIF9fYXNtX18oCiAiLnR5 cGUgICAiIFNUQVJUICIsIEBmdW5jdGlvblxuIgogIl8iIFNUQVJUICI6XG4iCiAiIiBTVEFSVCAi OlxuIgorIgkuYWxpZ24gMiBcbiIKICIJYmFsIDFmIFxuIgogIgkgbW92ZSAkZnAsICQwIFxuIgog IgkuZ3B3b3JkIC4gXG4iCkBAIC0xNSw3ICsxNiw4IEBAIF9fYXNtX18oCiAiLndlYWsgX0RZTkFN SUMgXG4iCiAiLmhpZGRlbiBfRFlOQU1JQyBcbiIKICIJLmdwd29yZCBfRFlOQU1JQyBcbiIKLSIx OglsdyAkZ3AsIDAoJHJhKSBcbiIKKyIxOglpbnMgJHJhLCAkMCwgMCwgMSBcbiIKKyIJbHcgJGdw LCAwKCRyYSkgXG4iCiAiCXN1YnUgJGdwLCAkcmEsICRncCBcbiIKICIJbW92ZSAkNCwgJHNwIFxu IgogIglsdyAkNSwgOCgkcmEpIFxuIgpkaWZmIC0tZ2l0IGEvYXJjaC9taXBzL3JlbG9jLmggYi9h cmNoL21pcHMvcmVsb2MuaAppbmRleCBiM2Q1OWE0Li43NzJiM2FhIDEwMDY0NAotLS0gYS9hcmNo L21pcHMvcmVsb2MuaAorKysgYi9hcmNoL21pcHMvcmVsb2MuaApAQCAtMzYsMTUgKzM2LDIzIEBA CiAjZGVmaW5lIENSVEpNUChwYyxzcCkgX19hc21fXyBfX3ZvbGF0aWxlX18oIFwKIAkibW92ZSAk c3AsJTEgOyBqciAlMCIgOiA6ICJyIihwYyksICJyIihzcCkgOiAibWVtb3J5IiApCiAKKy8qCisg KiBXaGVuIGNvbXBpbGVkIGZvciBtaWNyb01JUFMsIC5hbGlnbiBtYWtlcyBzdXJlIHRoYXQgLmdw d29yZAorICogaXMgcGxhY2VkIGF0IHdvcmQgYm91bmRhcnkuICRyYSBtdXN0IHBvaW50IHRvIGZp cnN0IC5ncHdvcmQuCisgKiBJU0EgYml0IG9mICRyYSBtdXN0IGJlIGNsZWFyZWQgZm9yIG1pY3Jv TUlQUyBiZWZvcmUgdXNpbmcgaXQKKyAqIGFzIGEgYmFzZSBhZGRyZXNzLiBGb3IgTUlQUywgSVNB IGJpdCBpcyBhbHdheXMgemVyby4KKyovCiAjZGVmaW5lIEdFVEZVTkNTWU0oZnAsIHN5bSwgZ290 KSBfX2FzbV9fICggXAogCSIuaGlkZGVuICIgI3N5bSAiXG4iIFwKIAkiLnNldCBwdXNoIFxuIiBc CiAJIi5zZXQgbm9yZW9yZGVyIFxuIiBcCisJIgkuYWxpZ24gMiBcbiIgXAogCSIJYmFsIDFmIFxu IiBcCiAJIgkgbm9wIFxuIiBcCiAJIgkuZ3B3b3JkIC4gXG4iIFwKIAkiCS5ncHdvcmQgIiAjc3lt ICIgXG4iIFwKLQkiMToJbHcgJTAsICgkcmEpIFxuIiBcCisJIjE6CWlucyAkcmEsICQwLCAwLCAx IFxuIiBcCisJIglsdyAlMCwgKCRyYSkgXG4iIFwKIAkiCXN1YnUgJTAsICRyYSwgJTAgXG4iIFwK IAkiCWx3ICRyYSwgNCgkcmEpIFxuIiBcCiAJIglhZGR1ICUwLCAlMCwgJHJhIFxuIiBcCmRpZmYg LS1naXQgYS9zcmMvdGhyZWFkL21pcHMvc3lzY2FsbF9jcC5zIGIvc3JjL3RocmVhZC9taXBzL3N5 c2NhbGxfY3AucwppbmRleCBkMjg0NjI2Li5jNjQ4Y2M0IDEwMDY0NAotLS0gYS9zcmMvdGhyZWFk L21pcHMvc3lzY2FsbF9jcC5zCisrKyBiL3NyYy90aHJlYWQvbWlwcy9zeXNjYWxsX2NwLnMKQEAg LTQxLDExICs0MSwxMyBAQCBfX2NwX2VuZDoKIAogX19jcF9jYW5jZWw6CiAJbW92ZSAgICAkMiwg JHJhCisJLmFsaWduCTIKIAliYWwgICAgIDFmCiAJYWRkdSAgICAkc3AsICRzcCwgMzIKIAkuZ3B3 b3JkIC4KIAkuZ3B3b3JkIF9fY2FuY2VsCi0xOglsdyAgICAgICQzLCAoJHJhKQorMToJaW5zICRy YSwgJDAsIDAsIDEKKwlsdyAgICAgICQzLCAoJHJhKQogCXN1YnUgICAgJDMsICRyYSwgJDMKIAls dyAgICAgICQyNSwgNCgkcmEpCiAJYWRkdSAgICAkMjUsICQyNSwgJDMK --_002_BD7773622145634B952E5B54ACA8E349DAE2DC38PUMAIL01puimgte_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11320 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Thu, 11 May 2017 03:25:47 +0000 Message-ID: References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1494473169 25960 195.159.176.226 (11 May 2017 03:26:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 May 2017 03:26:09 +0000 (UTC) Cc: Szabolcs Nagy , Andre McCurdy To: "musl@lists.openwall.com" , Rich Felker Original-X-From: musl-return-11335-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 11 05:26:03 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d8ejq-0006Zq-3I for gllmg-musl@m.gmane.org; Thu, 11 May 2017 05:26:02 +0200 Original-Received: (qmail 14084 invoked by uid 550); 11 May 2017 03:26:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 14066 invoked from network); 11 May 2017 03:26:03 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/A= In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11320 Archived-At: Hi Rich, Could you please find some time to review https://github.com/JaydeepIMG/mus= l-1/tree/micromips32r2_v3 branch? Thanks, Jaydeep >-----Original Message----- >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >Sent: 26 April 2017 PM 12:44 >To: Rich Felker >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >>-----Original Message----- >>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >>Sent: 25 April 2017 PM 10:23 >>To: Jaydeep Patil >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> >>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >>> > But syscall_cp.s needs some care because saved instruction pointer >>> >values are compared against these labels. In micromips mode, do the >>> >labels evaluate with the +1 low bit offset? >>> >>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However >>> I don't see any issue with following comparison >>> >>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >>> >>> The ISA bit will be set even for PC in the saved context. >> >>Agreed, I think it should work as expected. >> >>> >> >> diff --git a/src/thread/mips/syscall_cp.s >>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >>> >> >> --- a/src/thread/mips/syscall_cp.s >>> >> >> +++ b/src/thread/mips/syscall_cp.s >>> >> >> @@ -1,5 +1,5 @@ >>> >> >> .set noreorder >>> >> >> - >>> >> >> +.set nomicromips >>> >> >> .global __cp_begin >>> >> >> .hidden __cp_begin >>> >> >> .type __cp_begin,@function >>> >> > >>> >> >I'm also unclear on the motivation of this one. Before (v1) you >>> >> >had a lot of changes to replace .s files with something >>> >> >micromips-compatible (removing branch delay slots); now (v2) >>> >> >those changes are not included. So are .s files even being built >>> >> >as micromips at all? If not, why is the above needed? If so, how >>> >> >do the files >>> >with delay slots work? >>> >> >>> >> Branch delay slots are removed (called as compact instructions) in >>> >> the newer MIPS/microMIPS cores (in development). >>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot. >>> >> Assembler takes care of converting a BRANCH + NOP to its >>> >> appropriate compact instruction (BEQ + NOP to BEQC). >>> >> With the v1 branch I was trying to create generic hand-written >>> >> assembly which can be used for newer cores with the compact >>> >> instructions. >>> >> However I realized that it would appropriate to create a new arch >>> >> instead of creating generic assembly. >>> >> Thus in v2 branch I modified only those functions which would >>> >> create issues when compiled with interlinking on. >>> > >>> >Based on the discussions so far, I don't think pure-micromips >>> >qualifies as a new arch. If it would be possible to take a program >>> >compiled as micromips- only, and run it with the libc.so/ldso built >>> >for plain mips on a machine that supports both forms of code, then >>> >it's not a separate arch, and as I understand it this should be possib= le. >>> >>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new arc= h. >>> >>> >Rich >>> >>> I will create v3 if you are OK with this approach. >> >>OK. Can you factor it as one patch that's the minimal needed to make >>the .c files (including ones that include the crt_arch.h/reloc.h asm >>code) build correctly in micromips mode, which should be quick to >>review/accept, and a second (if you want to do this phase now; if not >>you can leave it til later) that makes the .s files micromips-compatible? > >Please refer to https://github.com/JaydeepIMG/musl- >1/tree/micromips32r2_v3 for changes (also attached as a patch). >I will push a separate patch to make .s file microMIPS-only compatible. > >>Rich > >Thanks, >Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11329 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Wed, 17 May 2017 08:28:21 +0000 Message-ID: References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1495009722 14388 195.159.176.226 (17 May 2017 08:28:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 08:28:42 +0000 (UTC) Cc: Szabolcs Nagy , Andre McCurdy To: "musl@lists.openwall.com" , Rich Felker Original-X-From: musl-return-11344-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 17 10:28:36 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dAuJu-0003cQ-TL for gllmg-musl@m.gmane.org; Wed, 17 May 2017 10:28:34 +0200 Original-Received: (qmail 17935 invoked by uid 550); 17 May 2017 08:28:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17917 invoked from network); 17 May 2017 08:28:38 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/D/wmZrAA== In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11329 Archived-At: Hi Rich, Could you please find some time to review https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch ? Thanks, Jaydeep >-----Original Message----- >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >Sent: 11 May 2017 AM 08:56 >To: musl@lists.openwall.com; Rich Felker >Cc: Szabolcs Nagy; Andre McCurdy >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >Hi Rich, > >Could you please find some time to review >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch? > >Thanks, >Jaydeep > >>-----Original Message----- >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >>Sent: 26 April 2017 PM 12:44 >>To: Rich Felker >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> >>>-----Original Message----- >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >>>Sent: 25 April 2017 PM 10:23 >>>To: Jaydeep Patil >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >>> >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >>>> > But syscall_cp.s needs some care because saved instruction pointer >>>> >values are compared against these labels. In micromips mode, do the >>>> >labels evaluate with the +1 low bit offset? >>>> >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However >>>> I don't see any issue with following comparison >>>> >>>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >>>> >>>> The ISA bit will be set even for PC in the saved context. >>> >>>Agreed, I think it should work as expected. >>> >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >>>> >> >> --- a/src/thread/mips/syscall_cp.s >>>> >> >> +++ b/src/thread/mips/syscall_cp.s >>>> >> >> @@ -1,5 +1,5 @@ >>>> >> >> .set noreorder >>>> >> >> - >>>> >> >> +.set nomicromips >>>> >> >> .global __cp_begin >>>> >> >> .hidden __cp_begin >>>> >> >> .type __cp_begin,@function >>>> >> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you >>>> >> >had a lot of changes to replace .s files with something >>>> >> >micromips-compatible (removing branch delay slots); now (v2) >>>> >> >those changes are not included. So are .s files even being built >>>> >> >as micromips at all? If not, why is the above needed? If so, how >>>> >> >do the files >>>> >with delay slots work? >>>> >> >>>> >> Branch delay slots are removed (called as compact instructions) >>>> >> in the newer MIPS/microMIPS cores (in development). >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot= . >>>> >> Assembler takes care of converting a BRANCH + NOP to its >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). >>>> >> With the v1 branch I was trying to create generic hand-written >>>> >> assembly which can be used for newer cores with the compact >>>> >> instructions. >>>> >> However I realized that it would appropriate to create a new arch >>>> >> instead of creating generic assembly. >>>> >> Thus in v2 branch I modified only those functions which would >>>> >> create issues when compiled with interlinking on. >>>> > >>>> >Based on the discussions so far, I don't think pure-micromips >>>> >qualifies as a new arch. If it would be possible to take a program >>>> >compiled as micromips- only, and run it with the libc.so/ldso built >>>> >for plain mips on a machine that supports both forms of code, then >>>> >it's not a separate arch, and as I understand it this should be possi= ble. >>>> >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new >arch. >>>> >>>> >Rich >>>> >>>> I will create v3 if you are OK with this approach. >>> >>>OK. Can you factor it as one patch that's the minimal needed to make >>>the .c files (including ones that include the crt_arch.h/reloc.h asm >>>code) build correctly in micromips mode, which should be quick to >>>review/accept, and a second (if you want to do this phase now; if not >>>you can leave it til later) that makes the .s files micromips-compatible= ? >> >>Please refer to https://github.com/JaydeepIMG/musl- >>1/tree/micromips32r2_v3 for changes (also attached as a patch). >>I will push a separate patch to make .s file microMIPS-only compatible. >> >>>Rich >> >>Thanks, >>Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11351 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Fri, 26 May 2017 03:46:49 +0000 Message-ID: References: <20170412192535.GG2082@port70.net> <20170412202721.GY17319@brightrain.aerifal.cx> <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1495770430 13489 195.159.176.226 (26 May 2017 03:47:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 May 2017 03:47:10 +0000 (UTC) Cc: Szabolcs Nagy , Andre McCurdy To: "musl@lists.openwall.com" , Rich Felker Original-X-From: musl-return-11366-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 26 05:47:05 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dE6DP-0003MY-Rm for gllmg-musl@m.gmane.org; Fri, 26 May 2017 05:47:03 +0200 Original-Received: (qmail 1433 invoked by uid 550); 26 May 2017 03:47:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1412 invoked from network); 26 May 2017 03:47:05 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/D/tJARoA== In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11351 Archived-At: Hi Rich, Could you please find some time to review this? Thanks, Jaydeep >-----Original Message----- >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >Sent: 11 May 2017 AM 08:56 >To: musl@lists.openwall.com; Rich Felker >Cc: Szabolcs Nagy; Andre McCurdy >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >Hi Rich, > >Could you please find some time to review >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch? > >Thanks, >Jaydeep > >>-----Original Message----- >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >>Sent: 26 April 2017 PM 12:44 >>To: Rich Felker >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> >>>-----Original Message----- >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >>>Sent: 25 April 2017 PM 10:23 >>>To: Jaydeep Patil >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >>> >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >>>> > But syscall_cp.s needs some care because saved instruction pointer >>>> >values are compared against these labels. In micromips mode, do the >>>> >labels evaluate with the +1 low bit offset? >>>> >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However >>>> I don't see any issue with following comparison >>>> >>>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >>>> >>>> The ISA bit will be set even for PC in the saved context. >>> >>>Agreed, I think it should work as expected. >>> >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 >>>> >> >> --- a/src/thread/mips/syscall_cp.s >>>> >> >> +++ b/src/thread/mips/syscall_cp.s >>>> >> >> @@ -1,5 +1,5 @@ >>>> >> >> .set noreorder >>>> >> >> - >>>> >> >> +.set nomicromips >>>> >> >> .global __cp_begin >>>> >> >> .hidden __cp_begin >>>> >> >> .type __cp_begin,@function >>>> >> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you >>>> >> >had a lot of changes to replace .s files with something >>>> >> >micromips-compatible (removing branch delay slots); now (v2) >>>> >> >those changes are not included. So are .s files even being built >>>> >> >as micromips at all? If not, why is the above needed? If so, how >>>> >> >do the files >>>> >with delay slots work? >>>> >> >>>> >> Branch delay slots are removed (called as compact instructions) >>>> >> in the newer MIPS/microMIPS cores (in development). >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot= . >>>> >> Assembler takes care of converting a BRANCH + NOP to its >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). >>>> >> With the v1 branch I was trying to create generic hand-written >>>> >> assembly which can be used for newer cores with the compact >>>> >> instructions. >>>> >> However I realized that it would appropriate to create a new arch >>>> >> instead of creating generic assembly. >>>> >> Thus in v2 branch I modified only those functions which would >>>> >> create issues when compiled with interlinking on. >>>> > >>>> >Based on the discussions so far, I don't think pure-micromips >>>> >qualifies as a new arch. If it would be possible to take a program >>>> >compiled as micromips- only, and run it with the libc.so/ldso built >>>> >for plain mips on a machine that supports both forms of code, then >>>> >it's not a separate arch, and as I understand it this should be possi= ble. >>>> >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new >arch. >>>> >>>> >Rich >>>> >>>> I will create v3 if you are OK with this approach. >>> >>>OK. Can you factor it as one patch that's the minimal needed to make >>>the .c files (including ones that include the crt_arch.h/reloc.h asm >>>code) build correctly in micromips mode, which should be quick to >>>review/accept, and a second (if you want to do this phase now; if not >>>you can leave it til later) that makes the .s files micromips-compatible= ? >> >>Please refer to https://github.com/JaydeepIMG/musl- >>1/tree/micromips32r2_v3 for changes (also attached as a patch). >>I will push a separate patch to make .s file microMIPS-only compatible. >> >>>Rich >> >>Thanks, >>Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11361 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Sat, 27 May 2017 22:00:57 -0400 Message-ID: <20170528020057.GD1627@brightrain.aerifal.cx> References: <20170413090036.GH2082@port70.net> <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1495936870 28026 195.159.176.226 (28 May 2017 02:01:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 May 2017 02:01:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11376-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 28 04:01:05 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dEnVx-00079R-J9 for gllmg-musl@m.gmane.org; Sun, 28 May 2017 04:01:05 +0200 Original-Received: (qmail 18400 invoked by uid 550); 28 May 2017 02:01:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18382 invoked from network); 28 May 2017 02:01:08 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11361 Archived-At: On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote: > Hi Rich, > > Could you please find some time to review this? I'm trying to catch up now. Sorry I've been behind on this. Rich > >-----Original Message----- > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] > >Sent: 11 May 2017 AM 08:56 > >To: musl@lists.openwall.com; Rich Felker > >Cc: Szabolcs Nagy; Andre McCurdy > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > > > >Hi Rich, > > > >Could you please find some time to review > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch? > > > >Thanks, > >Jaydeep > > > >>-----Original Message----- > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] > >>Sent: 26 April 2017 PM 12:44 > >>To: Rich Felker > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > >> > >>>-----Original Message----- > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > >>>Sent: 25 April 2017 PM 10:23 > >>>To: Jaydeep Patil > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >>> > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: > >>>> > But syscall_cp.s needs some care because saved instruction pointer > >>>> >values are compared against these labels. In micromips mode, do the > >>>> >labels evaluate with the +1 low bit offset? > >>>> > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However > >>>> I don't see any issue with following comparison > >>>> > >>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end > >>>> > >>>> The ISA bit will be set even for PC in the saved context. > >>> > >>>Agreed, I think it should work as expected. > >>> > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 > >>>> >> >> --- a/src/thread/mips/syscall_cp.s > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s > >>>> >> >> @@ -1,5 +1,5 @@ > >>>> >> >> .set noreorder > >>>> >> >> - > >>>> >> >> +.set nomicromips > >>>> >> >> .global __cp_begin > >>>> >> >> .hidden __cp_begin > >>>> >> >> .type __cp_begin,@function > >>>> >> > > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you > >>>> >> >had a lot of changes to replace .s files with something > >>>> >> >micromips-compatible (removing branch delay slots); now (v2) > >>>> >> >those changes are not included. So are .s files even being built > >>>> >> >as micromips at all? If not, why is the above needed? If so, how > >>>> >> >do the files > >>>> >with delay slots work? > >>>> >> > >>>> >> Branch delay slots are removed (called as compact instructions) > >>>> >> in the newer MIPS/microMIPS cores (in development). > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.. > >>>> >> Assembler takes care of converting a BRANCH + NOP to its > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). > >>>> >> With the v1 branch I was trying to create generic hand-written > >>>> >> assembly which can be used for newer cores with the compact > >>>> >> instructions. > >>>> >> However I realized that it would appropriate to create a new arch > >>>> >> instead of creating generic assembly. > >>>> >> Thus in v2 branch I modified only those functions which would > >>>> >> create issues when compiled with interlinking on. > >>>> > > >>>> >Based on the discussions so far, I don't think pure-micromips > >>>> >qualifies as a new arch. If it would be possible to take a program > >>>> >compiled as micromips- only, and run it with the libc.so/ldso built > >>>> >for plain mips on a machine that supports both forms of code, then > >>>> >it's not a separate arch, and as I understand it this should be possible. > >>>> > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new > >arch. > >>>> > >>>> >Rich > >>>> > >>>> I will create v3 if you are OK with this approach. > >>> > >>>OK. Can you factor it as one patch that's the minimal needed to make > >>>the .c files (including ones that include the crt_arch.h/reloc.h asm > >>>code) build correctly in micromips mode, which should be quick to > >>>review/accept, and a second (if you want to do this phase now; if not > >>>you can leave it til later) that makes the .s files micromips-compatible? > >> > >>Please refer to https://github.com/JaydeepIMG/musl- > >>1/tree/micromips32r2_v3 for changes (also attached as a patch). > >>I will push a separate patch to make .s file microMIPS-only compatible. > >> > >>>Rich > >> > >>Thanks, > >>Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11376 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [MUSL] microMIPS32R2 O32 port Date: Wed, 31 May 2017 09:11:50 -0400 Message-ID: <20170531131150.GH1627@brightrain.aerifal.cx> References: <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> <20170528020057.GD1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1496236330 4367 195.159.176.226 (31 May 2017 13:12:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 May 2017 13:12:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11389-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 31 15:12:05 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dG3Pw-0000v1-Oo for gllmg-musl@m.gmane.org; Wed, 31 May 2017 15:12:05 +0200 Original-Received: (qmail 18155 invoked by uid 550); 31 May 2017 13:12:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18122 invoked from network); 31 May 2017 13:12:02 -0000 Content-Disposition: inline In-Reply-To: <20170528020057.GD1627@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11376 Archived-At: On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote: > On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote: > > Hi Rich, > > > > Could you please find some time to review this? > > I'm trying to catch up now. Sorry I've been behind on this. OK. The only question I have is why the syscall_cp.s portion is needed at this stage. As long as all .s files are built as plain mips still (with support for building them as micromips to come in the future) it looks like this change belongs as part of that future patch. Rich > > >-----Original Message----- > > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] > > >Sent: 11 May 2017 AM 08:56 > > >To: musl@lists.openwall.com; Rich Felker > > >Cc: Szabolcs Nagy; Andre McCurdy > > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > > > > > >Hi Rich, > > > > > >Could you please find some time to review > > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch? > > > > > >Thanks, > > >Jaydeep > > > > > >>-----Original Message----- > > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] > > >>Sent: 26 April 2017 PM 12:44 > > >>To: Rich Felker > > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy > > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port > > >> > > >>>-----Original Message----- > > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > > >>>Sent: 25 April 2017 PM 10:23 > > >>>To: Jaydeep Patil > > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy > > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > > >>> > > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: > > >>>> > But syscall_cp.s needs some care because saved instruction pointer > > >>>> >values are compared against these labels. In micromips mode, do the > > >>>> >labels evaluate with the +1 low bit offset? > > >>>> > > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However > > >>>> I don't see any issue with following comparison > > >>>> > > >>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end > > >>>> > > >>>> The ISA bit will be set even for PC in the saved context. > > >>> > > >>>Agreed, I think it should work as expected. > > >>> > > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s > > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644 > > >>>> >> >> --- a/src/thread/mips/syscall_cp.s > > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s > > >>>> >> >> @@ -1,5 +1,5 @@ > > >>>> >> >> .set noreorder > > >>>> >> >> - > > >>>> >> >> +.set nomicromips > > >>>> >> >> .global __cp_begin > > >>>> >> >> .hidden __cp_begin > > >>>> >> >> .type __cp_begin,@function > > >>>> >> > > > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you > > >>>> >> >had a lot of changes to replace .s files with something > > >>>> >> >micromips-compatible (removing branch delay slots); now (v2) > > >>>> >> >those changes are not included. So are .s files even being built > > >>>> >> >as micromips at all? If not, why is the above needed? If so, how > > >>>> >> >do the files > > >>>> >with delay slots work? > > >>>> >> > > >>>> >> Branch delay slots are removed (called as compact instructions) > > >>>> >> in the newer MIPS/microMIPS cores (in development). > > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.. > > >>>> >> Assembler takes care of converting a BRANCH + NOP to its > > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). > > >>>> >> With the v1 branch I was trying to create generic hand-written > > >>>> >> assembly which can be used for newer cores with the compact > > >>>> >> instructions. > > >>>> >> However I realized that it would appropriate to create a new arch > > >>>> >> instead of creating generic assembly. > > >>>> >> Thus in v2 branch I modified only those functions which would > > >>>> >> create issues when compiled with interlinking on. > > >>>> > > > >>>> >Based on the discussions so far, I don't think pure-micromips > > >>>> >qualifies as a new arch. If it would be possible to take a program > > >>>> >compiled as micromips- only, and run it with the libc.so/ldso built > > >>>> >for plain mips on a machine that supports both forms of code, then > > >>>> >it's not a separate arch, and as I understand it this should be possible. > > >>>> > > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new > > >arch. > > >>>> > > >>>> >Rich > > >>>> > > >>>> I will create v3 if you are OK with this approach. > > >>> > > >>>OK. Can you factor it as one patch that's the minimal needed to make > > >>>the .c files (including ones that include the crt_arch.h/reloc.h asm > > >>>code) build correctly in micromips mode, which should be quick to > > >>>review/accept, and a second (if you want to do this phase now; if not > > >>>you can leave it til later) that makes the .s files micromips-compatible? > > >> > > >>Please refer to https://github.com/JaydeepIMG/musl- > > >>1/tree/micromips32r2_v3 for changes (also attached as a patch). > > >>I will push a separate patch to make .s file microMIPS-only compatible. > > >> > > >>>Rich > > >> > > >>Thanks, > > >>Jaydeep From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11379 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Thu, 1 Jun 2017 04:21:24 +0000 Message-ID: References: <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> <20170528020057.GD1627@brightrain.aerifal.cx> <20170531131150.GH1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1496290904 27269 195.159.176.226 (1 Jun 2017 04:21:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2017 04:21:44 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11392-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 01 06:21:39 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dGHcB-0006rz-9O for gllmg-musl@m.gmane.org; Thu, 01 Jun 2017 06:21:39 +0200 Original-Received: (qmail 1637 invoked by uid 550); 1 Jun 2017 04:21:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1608 invoked from network); 1 Jun 2017 04:21:41 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/D/tJARoP9mdSiA/sd34AD9jZjNEA== In-Reply-To: <20170531131150.GH1627@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11379 Archived-At: Hi Rich, In the previous version of this patch (micromips32r2_v2), I had suggested t= o build the .s files as pure MIPS code (using ".set nomicromips" directive)= . However change in reloc.h is still required as it could be inlined in a mic= romips function. Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 = instead.=20 Thanks, Jaydeep >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 31 May 2017 PM 06:42 >To: musl@lists.openwall.com >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote: >> On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote: >> > Hi Rich, >> > >> > Could you please find some time to review this? >> >> I'm trying to catch up now. Sorry I've been behind on this. > >OK. The only question I have is why the syscall_cp.s portion is needed at = this >stage. As long as all .s files are built as plain mips still (with support= for building >them as micromips to come in the future) it looks like this change belongs= as >part of that future patch. > >Rich > > >> > >-----Original Message----- >> > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >> > >Sent: 11 May 2017 AM 08:56 >> > >To: musl@lists.openwall.com; Rich Felker >> > >Cc: Szabolcs Nagy; Andre McCurdy >> > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> > > >> > >Hi Rich, >> > > >> > >Could you please find some time to review >> > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 >branch? >> > > >> > >Thanks, >> > >Jaydeep >> > > >> > >>-----Original Message----- >> > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >> > >>Sent: 26 April 2017 PM 12:44 >> > >>To: Rich Felker >> > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> > >> >> > >>>-----Original Message----- >> > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich >> > >>>Felker >> > >>>Sent: 25 April 2017 PM 10:23 >> > >>>To: Jaydeep Patil >> > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> > >>> >> > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >> > >>>> > But syscall_cp.s needs some care because saved instruction >> > >>>> >pointer values are compared against these labels. In micromips >> > >>>> >mode, do the labels evaluate with the +1 low bit offset? >> > >>>> >> > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. >> > >>>> However I don't see any issue with following comparison >> > >>>> >> > >>>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >> > >>>> >> > >>>> The ISA bit will be set even for PC in the saved context. >> > >>> >> > >>>Agreed, I think it should work as expected. >> > >>> >> > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s >> > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e >> > >>>> >> >> 100644 >> > >>>> >> >> --- a/src/thread/mips/syscall_cp.s >> > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s >> > >>>> >> >> @@ -1,5 +1,5 @@ >> > >>>> >> >> .set noreorder >> > >>>> >> >> - >> > >>>> >> >> +.set nomicromips >> > >>>> >> >> .global __cp_begin >> > >>>> >> >> .hidden __cp_begin >> > >>>> >> >> .type __cp_begin,@function >> > >>>> >> > >> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) >> > >>>> >> >you had a lot of changes to replace .s files with something >> > >>>> >> >micromips-compatible (removing branch delay slots); now >> > >>>> >> >(v2) those changes are not included. So are .s files even >> > >>>> >> >being built as micromips at all? If not, why is the above >> > >>>> >> >needed? If so, how do the files >> > >>>> >with delay slots work? >> > >>>> >> >> > >>>> >> Branch delay slots are removed (called as compact >> > >>>> >> instructions) in the newer MIPS/microMIPS cores (in >development). >> > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay >slot.. >> > >>>> >> Assembler takes care of converting a BRANCH + NOP to its >> > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). >> > >>>> >> With the v1 branch I was trying to create generic >> > >>>> >> hand-written assembly which can be used for newer cores with >> > >>>> >> the compact instructions. >> > >>>> >> However I realized that it would appropriate to create a new >> > >>>> >> arch instead of creating generic assembly. >> > >>>> >> Thus in v2 branch I modified only those functions which >> > >>>> >> would create issues when compiled with interlinking on. >> > >>>> > >> > >>>> >Based on the discussions so far, I don't think pure-micromips >> > >>>> >qualifies as a new arch. If it would be possible to take a >> > >>>> >program compiled as micromips- only, and run it with the >> > >>>> >libc.so/ldso built for plain mips on a machine that supports >> > >>>> >both forms of code, then it's not a separate arch, and as I >understand it this should be possible. >> > >>>> >> > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a >> > >>>> new >> > >arch. >> > >>>> >> > >>>> >Rich >> > >>>> >> > >>>> I will create v3 if you are OK with this approach. >> > >>> >> > >>>OK. Can you factor it as one patch that's the minimal needed to >> > >>>make the .c files (including ones that include the >> > >>>crt_arch.h/reloc.h asm >> > >>>code) build correctly in micromips mode, which should be quick to >> > >>>review/accept, and a second (if you want to do this phase now; if >> > >>>not you can leave it til later) that makes the .s files micromips- >compatible? >> > >> >> > >>Please refer to https://github.com/JaydeepIMG/musl- >> > >>1/tree/micromips32r2_v3 for changes (also attached as a patch). >> > >>I will push a separate patch to make .s file microMIPS-only compatib= le. >> > >> >> > >>>Rich >> > >> >> > >>Thanks, >> > >>Jaydeep