From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39911 invoked by alias); 24 Nov 2016 05:16:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 39753 invoked by uid 89); 24 Nov 2016 05:16:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=0400, xpg4, trimmed, Vanilla X-HELO: NAM03-DM3-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Thu, 24 Nov 2016 05:16:00 -0000 From: Yury Norov To: Maxim Kuvyrkov CC: GNU C Library Subject: Re: ILP32 for ARM64: testing with glibc testsuite Message-ID: <20161124051539.GA5365@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161107082359.GA19666@yury-N73SV> <20161109095650.GA22804@yury-N73SV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: VI1P194CA0021.EURP194.PROD.OUTLOOK.COM (10.175.178.31) To SN1PR07MB2255.namprd07.prod.outlook.com (10.164.47.149) X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;2:3ZqQ/xI3FbQUxxoHFZy4Jt1bQY0tSLmu20DE2OiPojRpPx3oV8q/9aw6vT6qvDhMT+FmYhcGrHfe5BE6zNuF+dYdkA5eo711FM8+TMZOXJyvNCsC2tHWHMNo23ZQDbWf4HnNKufTjwmun6MQKmHQrt6zgyfQr83VK7lfaMmjwYk=;3:T4ZhYDvcja4h8v94VRRPi4RpX85IHwFiHSLTV1qqPiNmv85hS/9Rg313nwWXFiw3DMSVCYgciyyUwjTIOpuh5J+LYyHafNBJtXPrHop3M7YxKbPzgUgN/2kW2XfTsg0/w1xBUqBLGP8abeXBeUOFQmEJqyhZ+LAd9wsTTmX6lu4= X-MS-Office365-Filtering-Correlation-Id: d9e71ccb-9f3f-43c5-765c-08d41428f7a6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR07MB2255; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;25:UP9AOrMCw4NwYT2UgVnk2h2WUoCUncf0WLQq6TEz5ahFkO74Il8FiewySRO7knx9icKgrLy2mH2GwQkCYz2dHlQhhEtrRo//kLiXBBOUioZNvn1cSmAz5hrPCU2AwEFO876mPs3jQOCQmCOXgAq0oV9iXz9S9vEOterNMH9QCodz/Eh1LlntuD7/c/76zlCZpQYusu1e7WGZoId6mc84G06SXbeESibPRtAcWubfqrLubM0jqsW4WbSUj9oftrAgiCpQckJUPd0F8Dt2zZaW4BZb2NibUiqqR3yHJxoymAiBXrxE7mZqm+jNQW8vnI8973ETN3lSFuCOapUYct0qOWiAQZ/o7yODwy/UrOOzVV6HhzOm+1dTZufC8+ZpBka7JtJy7ngtIGzfxv1+EutSYPOfXlgosesfNmabczFqokyDcALVj7pCYtxmlI2i0fw2clHjEQNSjKYDwO3b9VQsjvTA/8uEn0Bg+kW/a3Jac0kbk1aPMxWx9GfwnDOEwriMu2UaoP4NgEBNe4PBGiThWKe9qoJkehXScXpuI6UvIfWWZJbhU2wOHxFhSfSftwYfE/eD2dR1/NZYfJmzUygwMED5Wza+HIH+AnZj7NdHqDIkMscq05bJ1KKnyPhKtm/TvpNS2WTzUPA2f5MQ0GlWWIPAO3VcmyNBZEsQKDUwo5hB0nusaQ0iUzX+KgLN+GJmt5v4G1axQ34/DfFJ0ul2Z2MoIgCrQYRtgeQjmVLT/2zl7mblNQNTx+lm7vpfBdKDkILKkR8qecjMg10SuagrSTltFqv5nOR+uiOBXlj+Eo1UVjGlgGMx2K7LMputkNxm7xlcZDplru817iW1fKbC9Dukm5/+bUs6ibU2IB0klgwb0+kAwVKK/dNnzl91FkBhPyRVySaDHaYp+2NMDJcKz+eFCue2npCYb8+iQ+Iewlw= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;31:v+WrVFJ5G2Jhr526fUcdyelDthzi3QGx/oJq4s0t5kRdj370kaBepoU6m8tBubVO8CPGFiWzFCD+RB/18Ass5sVY0CkRaRwQLbjXlPlu9UnfJt44YHNy728fQ2HZzGdvxFRIZdY2HeRTKVaxH3VaMRe3q58U27A2gWO2xU2nWIkf6nQx9ZJ9tNmOQaeHlhsXMEchD30XqE+Y8S7302Rl2qTzaxzbuRM4u9C4mKpeGGDfgnoIjk4WTM2c1Le1FhTnj/wVSZCJnNzJYg28UiOCtr13RPc6pbJ4WGalRUdln9A=;20:Nyz+7wlgwdJqsYFyc1kuyc/A8uH9OuK7qRMNrcfyeQ2kFyZVTbR6lvD31Yf4CXMyNKBKYVCeAlySbmI0jV/W4sk0dy94mrXJrw4tYJyrPs7yZQlLMpwHarE8uny+LVlCJFRqOf71J0nZ9xMgfUPcTnHbL2K48UCs07DU5E76f74dSHr0gIVulik/tOaCyI94n9sF2vKN8d+6exYoGkL1L7z+jrwpP/hEFmRBZ4sfUHO4QGgPvW8hAvg034yU2lhH+VrPN+bBa5U7d8WHtuJMz8HvcxDfhJjxkWAIplIWUA4irtD7EPGZYHevqetFgWtz3ET0QcBjP73a8icuGzg4LfevWJgI6PDYqpVhvBiBV2ykEQHI2PuTkdutrL61uuClQgV4k4sXQtP2coGbeqEXi15BJDoI2O/xNhanoENSYudL6Uzn0F1GHRWWIXeJ0Qzp6V+NBpWBQq5Yq4bQfaLdOEi4lrTwvFy+P9J50zhNY2iTysQQo00+QDVPhGAopEwKoeVAcVKVJ3G2VIQ9v6tSIF0UuQiOjiweyw+NXnfUo1HlzzUxpWTeKd2f5yXytng6dT6lEFkBGheGKroHt/eWscqJpXQdDJUucxGqSJzm1U8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324);SRVR:SN1PR07MB2255;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2255; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;4:4G8Z1EupAEp2LYr0e0ef8IFD4HrzbVo5sW6qI7OSCmBRrD8dJWw1Lhuxr+B6DCbW9cN3V4VNjC7FAfk7/yBqQQrrIY1//BdzptGzqmwUOjEMDd8FPWDfeABLr3QzD0aL/IwE8baqNifIVySQdMepkMZU6rJlyTB7/eG+lK0wCidIBmk8jq8iYSPI7xwF71r7H3gXPUjS1kkia5vz1On9oD2waG8rEISUOdlh9PdBupzH8AoO6B4DjHlzy0QdJMHGo/2Nv0qIH1nNUJRLBhd3cwK3STNpCqtUFVTg6kAbDOReg9mKCUTxCWuJoe8xdzWWTRlJRTQ9n1tIpXUb6Nh/nhz5B4qPmMqoO7bAMeHXaqkDqgdtlAFy5okyTk7pgx9e9ID2bvSnBlPa0bzZSPZ+BbC83x/fop5/9CB9aYm04NCMRJd2qW3T2IhXebF34JDza8Pk5JXt2ANg7AbMYacS3KAL+tHMnM6mRNVhAGcqu33wBUqDKudyVUxcwy7UY6pDfXIWI6SpAkL2XLR4OlAH+i7h40bJfv8kKmULimGaM1c= X-Forefront-PRVS: 0136C1DDA4 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(377454003)(199003)(189002)(53754006)(24454002)(33656002)(33716001)(81166006)(68736007)(47776003)(92566002)(189998001)(66066001)(46406003)(83506001)(229853002)(4001350100001)(81156014)(15974865002)(9686002)(50466002)(97736004)(38730400001)(5890100001)(8676002)(76176999)(50986999)(6116002)(1076002)(7736002)(7846002)(4326007)(305945005)(54356999)(2906002)(101416001)(23726003)(76506005)(5660300001)(97756001)(42186005)(110136003)(3846002)(77096005)(2950100002)(6916009)(105586002)(93886004)(6666003)(106356001)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2255;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN1PR07MB2255;23:m3Fxo3OOycq0F4GPa1wWelTn1U1oaMzR+ht+Xsynd?= =?us-ascii?Q?rhK0FkUIoLBH+zybCHdVP5icqtcI6OmkhcPxXuilKQOeyXuMd+8+2hdb1n5h?= =?us-ascii?Q?MVJffYAYfwk67aeBcHyX+ld+sGNfExuHtduF6CEnYs/dq5ltvEJ+kGASruXJ?= =?us-ascii?Q?gRhH/DWamkXNlWbR6UdgjaJmbRU8zmlnGJxZNXVjRVQgqZlGen+DS92LXZ0P?= =?us-ascii?Q?Y/Gl+s+hJF/XcuhS6QB3oT30xPq8yQNkOPOnW0mYo+9A/DwKzGA9P3sKaE/K?= =?us-ascii?Q?nsUDMqJbYVFYfBddYw4w43m8Rs+l9c48XW7LL4EfTrHboIfo1R1qJOzsUEja?= =?us-ascii?Q?IDhtGS90ko9olsS5kgnTB1JMgzm9COJslQK9GwtA7HsQIw1qlxYL0Kod1tJF?= =?us-ascii?Q?g6+P9mwfovOFIgPijeYuvjxC+fdSbv7RevDWamVeue3BcxUJNODLAJNa8qpQ?= =?us-ascii?Q?v6Hvju6HxY2pc1VAh8W+4JHJqGWOssrSnHUwaMC+ZxFc3tpj6cRE+BFGBQ2a?= =?us-ascii?Q?X9eRlZEgI+bwrdyRQ5JMDXoxW5C85+crRKwuZKiO4GV1q6QT6PyyRhgTaVCz?= =?us-ascii?Q?yjY13W637iBfEMysW/yAkrA41hZ74op4T1CFvg8A7swdiL1kKngMrYr92AAV?= =?us-ascii?Q?dGSdHNLXcJYlQyv+4Ly0HOQ+/P8c2Hi4hUXQAkP17uahMlUYyRDtdrhr7MDH?= =?us-ascii?Q?VL8CLMYMJvhBTfEs85jtXlf257baswo24C3e5xX8k8G0CpTsbhMcjPS6N/XZ?= =?us-ascii?Q?4fpcbNBx5bQw93fOnP5PKL/ee/nxUP0GUOW3yoy0CxjeQDvpCm/J7xWzk0xP?= =?us-ascii?Q?lR0aC8KkkfO6clSMsb7QaU17JBWbwbmRilOBtsdGu0zMXGpuhagXTRCN/5Dv?= =?us-ascii?Q?kJM5OMv2JOPBSX937AsQDbNmTg36i+8QEHa8IrsieIncachtdVMEkRt9+ULV?= =?us-ascii?Q?ymh1NgHh5t3vw8/apF3GJWxYzra6y3H/QMXIjxQpHvURmEIQmtF7G6Dm6Cmj?= =?us-ascii?Q?X1zaGKw2mbLH7t4ntUANeTScpzEfEEDmTuu0WAlyk7g8n9Y3s9P6ry3pt/sg?= =?us-ascii?Q?w2PDGUO0S6wpAc3VeLolTnHhb+DcY0zbVRG3sN+jF10CEg9G+UZDUh/oI+aQ?= =?us-ascii?Q?6rqHUMH5RzMfxmZCxgDrRa+AvO79sYrmxnpv7LHZN3XNAt6xOoxyuI6W/TaO?= =?us-ascii?Q?gEVxs6g856+iQ0TrPOKoj6WQqFuv4IABLvSk9UFh2s+L8R1ZJyo8/nfBxOTF?= =?us-ascii?Q?d/mujDm++pJfE9FD0b1hyyA2aFwTJOwhw2uXTugCsb9uL3bVhgQEb3WUIDNj?= =?us-ascii?Q?WEkEtsev/nyN172cHH4bEH/SYGPzjmWH7ikD6rqG/st3sEmVcSM2acaZB3Id?= =?us-ascii?Q?mnkmA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;6:E+cMZe3S+WjcjxIkzAlIHL3Baa1vrLB/JaMj3qan3FwCnXSeCgS0gNLaR1X8hfkJAtHiPtmeH8iYkIV3Lf/JOTLJaa4Dus+VvAOPTOeope86PTV1pKw0+WjWCLb1mP5bdtQfhORYt6oS+PJuASBKHy7g3UrahcLLO6OvjOvkiPgQRcni6PfDjfXzLlC8dxAm3HpEUdgaP64NM1srffnu9v1gBEih1B46cJgkdciKoYZhp6LL+5ugy4QfsT6Z93+bQo/mZwAU1KzYp6BMxNjH9sJIS2vo4FUwZNG0oAuSOiIfLrnvnIDD7eFAt/C/D4T0PZVaNfJ8uK4gDKEWXqILggcVwesWou2WyQXcgADbMzo=;5:hUmcRokuVxLQkCfyFIQc+vF4g2P1PvnuHKHbA3FAipFK3qm+ILiYXQtRp9u/QfYb3OYvLRsw/cd6YrURXNPKzvcF2kQSP9MTmgtpcSp48dL74lixV14T475Su5ARB4E8oCCZzvQAO8wwy/fMAvtyvg==;24:qmxGwLJx6KIyKDCGipFdhBtYQDLvX7SWcob9IiwC5ZbhpHhyqehf65E01r6zEKBWfrs30CkcAI5ky1l+pAxYX0y2jl9LrTLBXS5UkYSNE/4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;7:i9CN5s/QoJu/Dm1M2B8NdCoASWGLOlVNgeLLpDwP6QYuXesoq94lZK6RHiewaCZjaGxYpEqSdyO5NTiAIv46WPa55KagupQKI9z2wpfOF/Nt1vb7qvGU6D7DJOxjQB2GsnIdB9bCk5Jn3ony6RwzV75yzhSFNK6WkUHyw4nQ6bcMeiltDnbmVOYVMaLL559Wg/dVGyLQs/SRSGCwo+J63YkLkKZrgAftjbLbGMJVy8VCiJZ2mPp7B521/E12F71G95ztYO8daz5UXlrLyZWvzotMdNCDzCruCg/q3RDvqhTW11eQEqj8MVAqWzeUlfZryXiL9xkwh3AMzo1ltje+sbAJryQ+pP+Q56oHpXyy2vY= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2016 05:15:54.3584 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2255 X-SW-Source: 2016-11/txt/msg00869.txt.bz2 On Wed, Nov 16, 2016 at 03:25:40PM +0400, Maxim Kuvyrkov wrote: > [Resending with trimmed CC: to avoid libc-alpha's spam filter] > > > On Nov 9, 2016, at 1:56 PM, Yury Norov wrote: > > > > On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote: > >> Hi all, > >> > >> [add libc-alpha mail list] > >> > >> For libc-alpha: this is the part of LKML submission with latest > >> patches for aarch64/ilp32. > >> https://www.spinics.net/lists/arm-kernel/msg537846.html > >> > >> Glibc that I use has also included consolidation patches from Adhemerval > >> Zanella and me that are still not in the glibc master. The full series is: > >> https://github.com/norov/glibc/tree/ilp32-2.24-dev2 > >> > >> Below is the results of glibc testsuite run for aarch64/lp64 > >> in different configurations. Column names meaning: > >> kvgv: kernel is vanilla, glibc is vanilla; > >> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; > >> glibc is vanilla; > >> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; > >> kege: kernel patches are applied and enabled, glibc patches are applied. > >> > >> Only different lines are shown. Full results are in attached archive. > > Hi Yury, > > The general requirement merging ILP32 glibc patches is that LP64 does not regress in any reasonable configuration. This means that there should be 0 regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without ILP32 patches does not regress on the vanilla kernel. The kvge configuration is not in your testing matrix, and I suggest you make sure it has no regressions before fixing the more "advanced" configuration of kege. > > Ideally, there should be no regressions between kvgv and kege configurations, but I don't consider this to a requirement for glibc acceptance of ILP32 patches, since any regressions between kvge and kege configurations are likely to be on the kernel side. > > Speculating on the kernel requirements for ILP32 kernel patchset, I think there should be 0 regressions between kvgv and kdgv configurations, where you have only 3 tests to investigate and fix. > > [I do appreciate that there are progressions in your results as well, but the glibc policy is that they do not offset regressions.] > > The above only concerns LP64 support in kernel and glibc. > > Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have extra failures compared to LP64, since these are not regressions, but, rather, failures of a new configuration. From a superficial glance is seems that ILP32 linknamespace support requires attention, as well as stack unwinding (judging from NPTL failures). > > > -- > Maxim Kuvyrkov > www.linaro.org Hi Maxim, others, >From last email we have fixed major part of fails, and also tested vanilla kernel with ilp32-enabled glibc, as Maxim asked (kvge column). Source trees: https://github.com/norov/glibc/tree/ilp32-2.24-dev5 https://github.com/norov/linux/tree/ilp32-4.9-rc4 Some fails analysis is below. ILP32 LP64 kvge Vanilla c++-types-check FAIL PASS PASS PASS conform/ISO/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/ISO11/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/ISO99/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/POSIX/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/POSIX/sys/stat.h/linknamespace FAIL FAIL FAIL PASS conform/UNIX98/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XOPEN2K/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XPG3/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XPG4/stdio.h/linknamespace FAIL FAIL FAIL PASS elf/check-localplt FAIL FAIL FAIL PASS elf/tst-tls1 FAIL PASS PASS PASS elf/tst-tls1-static FAIL PASS PASS PASS elf/tst-tls2 FAIL PASS PASS PASS elf/tst-tls2-static FAIL PASS PASS PASS elf/tst-tls3 FAIL PASS PASS PASS iconvdata/mtrace-tst-loading FAIL FAIL FAIL PASS iconvdata/tst-loading FAIL FAIL FAIL PASS io/check-installed-headers-c FAIL FAIL FAIL PASS io/check-installed-headers-cxx FAIL FAIL FAIL PASS localedata/mtrace-tst-leaks PASS FAIL FAIL PASS localedata/tst-leaks PASS FAIL FAIL PASS malloc/tst-malloc-backtrace PASS PASS PASS FAIL malloc/tst-malloc-thread-exit PASS PASS PASS FAIL malloc/tst-malloc-usable PASS PASS PASS FAIL malloc/tst-mallocfork PASS PASS PASS FAIL malloc/tst-mallocstate PASS PASS PASS FAIL malloc/tst-mallopt PASS PASS PASS FAIL malloc/tst-mcheck PASS PASS PASS FAIL malloc/tst-memalign PASS PASS PASS FAIL malloc/tst-obstack PASS PASS PASS FAIL malloc/tst-posix_memalign PASS PASS PASS FAIL malloc/tst-pvalloc PASS PASS PASS FAIL malloc/tst-realloc PASS PASS PASS FAIL malloc/tst-scratch_buffer PASS PASS PASS FAIL malloc/tst-trim1 PASS PASS PASS FAIL math/test-double PASS PASS PASS FAIL math/test-double-finite PASS PASS PASS FAIL math/test-idouble PASS PASS PASS FAIL misc/tst-writev NA NA NA PASS posix/tst-getaddrinfo4 PASS PASS FAIL PASS posix/tst-getaddrinfo5 PASS PASS FAIL PASS nptl/tst-cancel26 FAIL PASS PASS PASS nptl/tst-cancel27 FAIL PASS PASS PASS posix/tst-regex2 FAIL FAIL FAIL PASS rt/tst-mqueue1 FAIL PASS PASS PASS rt/tst-mqueue2 FAIL PASS PASS PASS rt/tst-mqueue4 FAIL PASS PASS PASS rt/tst-mqueue7 FAIL PASS PASS PASS stdlib/tst-makecontext3 FAIL PASS PASS PASS sunrpc/bug20790 PASS PASS NA NA sysvipc/test-sysvmsg PASS PASS NA NA sysvipc/test-sysvsem PASS PASS NA NA sysvipc/test-sysvshm PASS PASS NA NA Conform tests fail most probably because I have vanilla headers at standard paths (/usr/include). Modified headers are under different testing location. Steve also tested it, and he has modified headers at /usr/include, and he doesn't see failures of conform tests. I don't think that kernel or wrong ABI caused this regression. Most probably it's configuration issue. I also think that glibc should take headers from testing directory, not from standard paths. For me it's dangerous to replace standard headers with untested ones. Is there some option in glibc testsuite configuration to provide path to headers explicitly? elf/* tests fail only in ILP32 mode. We tracked it down to the linker problem that replaces accesses to TLS with direct address calculation if possible, and does it wrong for ilp32. This is definitely a linker problem, and ABI and kernel are not involved here. iconvdata/mtrace-tst-loading, iconvdata/tst-loading, io/check-installed-headers-c and io/check-installed-headers-cxx are most probably failing due to installed headers, like conform tests. localedata/mtrace-tst-leaks and localedata/tst-leaks fail only for me. Steve has it passed. I'm not sure but it also looks like configuration issue, or similar. posix/tst-getaddrinfo4 and posix/tst-getaddrinfo5 check broken URLs. We should investigate it, but I don't think it's ABI issue. Also, if I run them manually, they return 0, which means they are passed, I suppose. nptl/tst-cancel26, nptl/tst-cancel27, rt/tst-mqueue1,2,4,7 are also looking like the TLS issue. posix/tst-regex2 and stdlib/tst-makecontext3 fail only for me, so it's probably my local problem. So, with all regressions still been in the list, major part is looking like my local configuration problems. Others fail due to linker wrong behavior. I don't see any obvious failures caused by kernel or ABI errors. Yury.