Message ID | 1473166521-24827-1-git-send-email-ynorov@caviumnetworks.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 90595 invoked by alias); 6 Sep 2016 12:55:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 90582 invoked by uid 89); 6 Sep 2016 12:55:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: NAM01-SN1-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; From: Yury Norov <ynorov@caviumnetworks.com> To: <libc-alpha@sourceware.org> CC: Yury Norov <ynorov@caviumnetworks.com> Subject: [RFC PATCH] __fxstat: replace if() with #if when checking version Date: Tue, 6 Sep 2016 15:55:21 +0300 Message-ID: <1473166521-24827-1-git-send-email-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: AM5PR0101CA0001.eurprd01.prod.exchangelabs.com (10.169.240.11) To SN1PR07MB2253.namprd07.prod.outlook.com (10.164.47.147) X-MS-Office365-Filtering-Correlation-Id: dec9df3b-dcca-4d69-6432-08d3d65516c0 X-Microsoft-Exchange-Diagnostics: 1; SN1PR07MB2253; 2:wzL+g5w3jH8X1d+O1tu+Lh5OCG0x6luB7C9Gh2WOSDS8v7qCzMY5oJ/MsyQldmmYZpOu7j/mT6CNgzMGDFfH/sxJ8xsEaBr6ZTD5rfyA56Knbtm/PIsatJAOJPD78/a5l51Lhhe+0GEi3eGkQrZcfsvBoUrYKmA7zQvsyEJQC03sRhDUw/ehxhyQaruzI7TE; 3:354TTtEL5kYFB/3KKhxYF+RC1CEQKZttrjFM3gkUGEnj1DE/YIMlddCT25CMWFNo2OtMZM547KVRgx+u1Jy6mB4R1NKqPlcGd5CLSZ10zWbuk1+fzZiM5SbmwJlsD/Y/; 25:CeMOzdn4kvbtEnH97M2M0x9wGiTHsrcg8x/1GlQ8kH55o6Uw6zy531LwP8QhzM4vxeiEQzeNstl524dTSnsY74EAWGLhALfCBW0gj/ZMUX5lv0q2RDDl9Yf+Urmh7q7H9kI/fGxw8tRWKI00IvroV2oRetOsNWh0lB/GgAXcDnvuKBvDJHrt4r6eTbGHR3rDuLkJJEyhv/whNON1kX3NyAPQWTQ9uVo67k6YeGCbvYRe5DW8nK5rRi4vlv0pZXWW5lF3MVOTL8FWoZiO95U7quP8dQtiivZU2IlztcND96HBCTnUq7Rpdcl88ne8n1vpz36nZCBzBIyEPP71GtUxJ1jcmuaaJuESFf6rRaG1fgrFEjlXAknQR6sF8uAV7Bab8ULXAIZs156CMz96MbjmR7qYLTxJkX5nZcFkEcR2+z0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2253; X-Microsoft-Exchange-Diagnostics: 1; SN1PR07MB2253; 31:ST8xHXWPYw9DVTi7Tj+Qe7mpMBjMLdTKn+lCExxGXdqUd4+m/zhdsslmoWDVkh9alH2/ZPnMncQMAbNAv/ElN8Jjyl8gWULcBzJtIJ7Iayx4uP7MnE7FZ1c/+YspnTgPjuBm7EK5CLKlWg1l9b/tuoVVfkrQ08MUPBezgbBeC+wUpeTkk3XMifCjd4Hjq7H43ak7RH0xhbtP3IbdrC4s9lt6JrV+LH18HMXbDMKMV7w=; 20:sIiwXTz4VUgW4e/aaEdZ7/SBdVT2rWSWBEfGOFj4hyo0rYkuM/wqQb+tFJCrv6akBNQYkuTwy6VBATdED4tRC7dBBsOfg9w2Nq/HRMrtV2Aj1bhaidA/9PAj4/XlH74BADOrMVFLNI9a1q0QC1iGcGN9OhH4WLnIEkoUVFhGzujW6laoZJKUtH8UWp/Eim2LVQ4sYTH0u4iqygJ/+u+WbOeGDCPPK+yaoooUA48SUVxMfYPH6RU3aU15ptz5HG782TM1gyJ81/rhlSPhRDZWHJ1o8C6pKYNIEfHzywyecR7Xvgrmp95p8hfToRFcbJtsOATvZ2IWCl7XOdRSLGYUFbH9zNWebQfJFH08PDvnT6GcUTDYcjcuodIkkdvZS4u7TNw9kGK2sYxy8NKXlclO/zlEYKwfrsNo6v1mVog2W5bwgz20ip0s6787yUQS5O3+HP/NUkF3FBihJEJnhDBplCVrJlk/bqHpSXhT/Ju2ulx/f5ZkEF+P9aRx3wgfKP2RTTWDZpoNYKRX3em8Yim9F6HsMkZIYoaobe9Zvp+o772n4e0410jt8vzacxcG8BrQNb8dhQm/5HafR7OC3ncBj87Tc5xcflv2qen39GVJV/Y= X-Microsoft-Antispam-PRVS: <SN1PR07MB2253E1DF1DA7F21F6DCA9C02EEF90@SN1PR07MB2253.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR07MB2253; BCL:0; PCL:0; RULEID:; SRVR:SN1PR07MB2253; X-Microsoft-Exchange-Diagnostics: 1; SN1PR07MB2253; 4:du6/1/ciiijA8SdDaX4uMf8V0zPndY/caYOmgCzwlIa+FNaSAx723UpY1w96xf+TjzsH+tP4AVKFsu7UVw0zhErs1phx9bUHVgQWga95q10f2gOuW+YzqigcYdDeEDC9N5FddytbnKkZc9iBM4XC2r+k3/q861vvYv/lCelAe8zjLsGJyOz4PSJ/cCgZuyxW+EAWBOSeclarS13x372FIQ6QO7MyRSBvotyTIto9yROUWgL4IQS9gWNqps57Y59JeHwHNY85WAH9lCMb/swPT80FwJO+5D6IwqHndU88Y5Tueuz5KC/NO/2F6ZrWxoLGyVXk5CmtBDIsaGkKomslMzlsUZhmEh8SE370LUFWBQMNrtvYNZ/udJ+AHKWWQZ2P56EtPZu52It+OMKe/wWTiw2yS7cMAPCBcKTS6OnR3kDQKCjt22bObB+xhOdIkRsv X-Forefront-PRVS: 0057EE387C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(199003)(189002)(68736007)(50986999)(77096005)(2351001)(42186005)(101416001)(47776003)(5660300001)(105586002)(66066001)(76506005)(7846002)(48376002)(7736002)(305945005)(189998001)(50226002)(110136002)(107886002)(19580395003)(19580405001)(3846002)(92566002)(2906002)(4001430100002)(6116002)(50466002)(450100001)(33646002)(8676002)(81166006)(81156014)(106356001)(229853001)(5003940100001)(586003)(4326007)(97736004)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR07MB2253; 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; SN1PR07MB2253; 23:t72rwbxQXLVahzbC8+JXCHhGkUA0AXsIogEdb/fQT?= =?us-ascii?Q?EMJ3X4a9j2qtj4UjkjJVxkrOWNWy8VmBev/FzHbdlnd1GiDOJUH2ABH/YvZ5?= =?us-ascii?Q?zNd+yXUP9Yi6FsulV3tiPIRbucti5+e4Q98n8LuBZ9+kaYX70hm4wiTfdj/S?= =?us-ascii?Q?MYPYSWK1UEWjRzJwquY1vbbgL1oNFseDNf3CHyJajNC8AZlcSi5pFQBOWoZn?= =?us-ascii?Q?ZwCfQEgyjFbBcIIUgaiuqHEYeD2NNLaNhY2lCFTvDr4tvsjxXl8KEM8g4L+l?= =?us-ascii?Q?SV4SBcOxuj8PtAZCfvDZtP5XphLaCHqzcWQEcOG3q61ASuUrphIqQsEFQbFU?= =?us-ascii?Q?j1T6EXzJ3yAabFFA6H9tq0zAKAwf0ljR9xQBgqa0wANWgWLLr1ZsrgV6p/Rh?= =?us-ascii?Q?3njdYluUq4WKCeT2f1UKthy74gYEtEMCdrrhToPjVup/lyW4G4TQtRZ8YjXN?= =?us-ascii?Q?xJ3A9MUY0G8wTjLRn0P4h5ZIqddlsIAet0IomxFoLWbLVQmBHPPbP3D6+rV6?= =?us-ascii?Q?+PMOsvkPb8BbfMbO18HpFzptRO1091VBxTyoauYkrOlLLtxca4Z0P1SjCK09?= =?us-ascii?Q?+tXVA+8Bqs4P//MEk5H7NBSNNHaIkRFRsXCEDAcYJv76VncXv4zJ5BoCAZ0V?= =?us-ascii?Q?8m8BthKEDwH24v6qXvbWOOpm4MyeMbrI3S1WOYxMaUUKmlrfpktAcB2OIlix?= =?us-ascii?Q?locQ/S64rYksO3OjLBpj6BovPike/yvOaKV2+/k1q4TijJDpR5RXA1q8RWeX?= =?us-ascii?Q?2ZRs8LLyWRvsrxNMz9Qb71j24dfY/ingwP1eM0qQCTY5fEIG/I1OBYY/9Ra5?= =?us-ascii?Q?q7FgIS67Wl4vYpL6ha3j4GCijLxxd5+appmgxZaYGsauhjTeBzqKTNp6SMiU?= =?us-ascii?Q?ctwzPuGqznRirP2XFSFNd9X1kD0OTqzrst0JX9txJhkkMaV2r6q6RU8b9FAs?= =?us-ascii?Q?uUyS4RTIy+7IPlSM/cSZv816XMEObdQi2yehhcts70MdJyKrsaWb3bnjRrEj?= =?us-ascii?Q?N07nZgzLdYTFs0U7NUdZpza77T256e8rv1DTj4yKGDs2PdzXTmnyqoBQfSnO?= =?us-ascii?Q?sTFMJhCKJOXH0qru6P6SQoTOmNEBT/xSZt64q4OAwGMS6py2iPM4xFzj9HWW?= =?us-ascii?Q?LPPlWEt1L5aV0yugakoJKu2xnW+eHy2?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR07MB2253; 6:FhuxXno85iEsMto6huQlfVpsrFRJpR0tElFAtbvMl0bcnFcitKboa0Hjo6zyegCI104JthH3ELQPalzs6ENNQSKVt0rdrqWjsuYCsK+ndmoJRC4MqYFfWApnN4GfdDgHkAiJ1U3h9uWp2mKku91INkzU9m2scQhDZgFaAEzZUUMx0Ef2rS5dQMrQWvnrbfG2oyEKwFPjPzzbQZJZm6fzYd7VFx2eIbRE23bXQh4xmEbsh1RsgoP/rbd+aA6e+FRtesd3RKDR2lt56gn3r76YRfQbbDMqqxuCd+L1L24aqgA=; 5:M3+osEBpINazlnENq9SpmZY/4X5qWdmAf0uyjO5oaijlPwVVvBzQah/V9UwOkob1mcSAFvTfMvUy+vND/uvRf2Z3rLJy9z8Bnu+aue8LlFlMCnnjNhmur/u4B76RdrVnKGhgXkFN/WGhAot/adRJ2A==; 24:TRcIskNahHN5VSASgMGYtDZUczeomKTT9jHzGkpgyuLekeHgc46jqqy/KeMEFu1z6wcrbl9uVSJPnh6g0AlMlM1Y3O7Uphs2jm96/ijOTPE=; 7:BwuhB/ZUzYj5CDJ7SF7/lLpkgrKyv4q5Vdc854b2CS7pI7JqDW46Xvdez3UT8JyIMuq68GejZ3e666Yl2tFIqL33fZrc2mfhTwBrrPmJdfKwlFVGhFgD8SaI9l9Ig9grsKTXPhhjkINJ52aaaXbUgFdCMofLMsQSzKSpshW/9DLtNFIMdhKbfu3q+WQjddrMKdz02BsNQNBjuJz5eh1tU/+EogjDoVR4yEbEj+k4CoomZYHV4xKz/pXF7ptv4/5f SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Sep 2016 12:55:32.8049 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2253 |
Commit Message
Yury Norov
Sept. 6, 2016, 12:55 p.m. UTC
__fxstat() is always passed with _STAT_VER as vers parameter and it's
in internal namespace.
It means we can replace runtime argument check with compile-time #ifdef.
It helps to make the body of _fxstat() smaller, and suppresses errors
if struct kernel_stat or __xstat_conv() is not declared, when they
are not needed.
If patch is found reasonable, I can check and fix other platforms and
stat syscalls. Could someone explain me, what for we need 'vers',
if we pass it with the only value everywhere. Maybe it's time to remove it
completely?
* sysdeps/unix/sysv/linux/fxstat.c: Replace if() with #if
when checking version
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
sysdeps/unix/sysv/linux/fxstat.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
Comments
On Sep 06 2016, Yury Norov <ynorov@caviumnetworks.com> wrote: > __fxstat() is always passed with _STAT_VER as vers parameter and it's > in internal namespace. It is part of the glibc ABI. > If patch is found reasonable, I can check and fix other platforms and > stat syscalls. Could someone explain me, what for we need 'vers', > if we pass it with the only value everywhere. Maybe it's time to remove it > completely? _STAT_VER has changed over time. Andreas.
On Tue, Sep 6, 2016 at 8:55 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > __fxstat() is always passed with _STAT_VER as vers parameter and it's > in internal namespace. > > It means we can replace runtime argument check with compile-time #ifdef. > It helps to make the body of _fxstat() smaller, and suppresses errors > if struct kernel_stat or __xstat_conv() is not declared, when they > are not needed. We can't do this. I think you may have already figured this out, but let me write out a clear explanation for the benefit of future people who may have the same idea. _STAT_VER exists because the contents of struct stat have changed over time. When an old executable is used with a new C library, the 'vers' argument will indicate that the executable expects the old layout, and the library will translate from the kernel's (presumably newer) stat layout to the executable's older expectations. It is the same problem that the kernel solves by changing the syscall numbers for stat/fstat/lstat whenever they change the structure. Therefore, the 'vers' argument *can* vary at runtime, even though all the code in the *current* source tree always passes the same value. To make this work, we have inline functions in <sys/stat.h>, backed up by out-of-line copies in libc_nonshared.a, that present the documented API (stat/fstat/lstat) and call __xstat/__fxstat/__lxstat with the additional argument. That is why these __-name functions are part of the public ABI for libc.so. Same principle as __printf_chk for instance. If we were designing this mechanism today from scratch we would probably use symbol versions - unless there's some nonobvious reason why that wouldn't work - but this mechanism *predates* symbol versioning. It has been around since the 1990s if not earlier. Maybe you could look into arranging to use symbol versions from now (or better, the next time the kernel changes the stat structure) going forward. But the old __(|f|l)xstat symbols need to stick around for binary compatibility, and their implementations need to test their 'vers' argument at runtime. zw
diff --git a/sysdeps/unix/sysv/linux/fxstat.c b/sysdeps/unix/sysv/linux/fxstat.c index e33023b..2e79f8b 100644 --- a/sysdeps/unix/sysv/linux/fxstat.c +++ b/sysdeps/unix/sysv/linux/fxstat.c @@ -35,20 +35,22 @@ int __fxstat (int vers, int fd, struct stat *buf) { - if (vers == _STAT_VER_KERNEL) - return INLINE_SYSCALL (fstat, 2, fd, buf); +#if _STAT_VER == _STAT_VER_KERNEL + return INLINE_SYSCALL (fstat, 2, fd, buf); +#else -#ifdef STAT_IS_KERNEL_STAT +# ifdef STAT_IS_KERNEL_STAT return INLINE_SYSCALL_ERROR_RETURN_VALUE (EINVAL); -#else +# else struct kernel_stat kbuf; int result; result = INLINE_SYSCALL (fstat, 2, fd, &kbuf); if (result == 0) - result = __xstat_conv (vers, &kbuf, buf); + result = __xstat_conv (_STAT_VER, &kbuf, buf); return result; +# endif #endif }