Message ID | 1466485631-3532-2-git-send-email-ynorov@caviumnetworks.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 102175 invoked by alias); 21 Jun 2016 05:07:55 -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 102048 invoked by uid 89); 21 Jun 2016 05:07:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:na01-bl, H*r:65.55.169, H*r:sk:mail-bl, apinski@cavium.com X-HELO: na01-bl2-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>, <linux-kernel@vger.kernel.org> CC: <arnd@arndb.de>, <catalin.marinas@arm.com>, <marcus.shawcroft@arm.com>, <philb@gnu.org>, <davem@davemloft.net>, <szabolcs.nagy@arm.com>, <maxim.kuvyrkov@linaro.org>, <joseph@codesourcery.com>, <pinskia@gmail.com>, Andrew Pinski <apinski@cavium.com>, Yury Norov <ynorov@caviumnetworks.com> Subject: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons. Date: Tue, 21 Jun 2016 08:06:44 +0300 Message-ID: <1466485631-3532-2-git-send-email-ynorov@caviumnetworks.com> In-Reply-To: <1466485631-3532-1-git-send-email-ynorov@caviumnetworks.com> References: <1466485631-3532-1-git-send-email-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: HE1PR03CA0031.eurprd03.prod.outlook.com (10.163.170.169) To DM3PR07MB2252.namprd07.prod.outlook.com (10.164.33.150) X-MS-Office365-Filtering-Correlation-Id: a2b35935-5721-4542-a6a5-08d39991f7af X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 2:Fz9jLOc/7hYpyLE1k/WNDORRS23lxRp4vaZ/ThHl9r6IxDZuHAFBwr0Z6SLxT/qLbOpf3GUe2tH01+UiMAqDvjgx/hyByqgCKeJDv68eTAccxI5kf9b0YqjX8dbfe8GEvCsfACoHU2L1ZxRUC6KpGC1jwP4472L6RaQp53cc3EqzqQsFqLoMR+S48kMvTcGq; 3:b4lRVntjsMJU6fRULcGd+RAv2G6DyftLk15Qzcj/PNoUjZVC0oeYAxt9AqxGTVAJXIzV+VxUfZQJi5/Hs7EO/4zy3JN7TSdV35TqrwM8YeJG0JbbBB26TEM5FCi7lEpb X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 25:PyQQECmgJ8hUwPQIEQrMjk9bBwW+ZHCfbdh0dya6HYJ80WmizZug5E2wLwoz8KVoxK+xQf8lm4yf2tYXzbpim7AIM86Qp3+ib0l85CF0ZwtcaihjZ+6jC+kVhY7JKb6usysK+f+LDjGGcb/pNwLAGuWz96mwoK84qLpqc+KXoRJ1eSbbYXRggT74nmot6Lhu04pQvbMjT4GzTWqCq1oiqhzmNTLx3+CBpZmbaQcSjWVj6wVUKZzxMTE1T7fSU4AwKqn0kWVVaQXNwwq1G8AQuJv2E29uA3Ya20sfxkABr+8rlTUZJpyw48qIDy7Yh23lAyobd9xRj/VzyqfaJSBWbr0vv+/QeJd7usINKEm6pCmUI58F335bWGTZQd2Km51nbzqfyp8jnnMhwTZFl/rjgiTGLmN8PoCigkKeRBdTyI3c9z4J+J/0LbHY+0gPpzKZ8cI8G9hwGOYwQCWZ11nwDjlgMZvdLbYD6zm/yOae92cvCuoOxgZf0lUhu7TzRzQyXNC5uzFIsLLKhpoSpGqPIbvJdHpKKGt4w2izLZg9bU9blZ6snhb8xpIeJ6vVBAV0DS5+tbaSVFosXx3x3VYkbNhMCC1GA9ABpGMD9M6be4jIRxjOLF6yzaYFlvTlYn9uDDDpwXLOhFNcP9ggAR8a/LqSQThU7zWdahrTLxY2dF77r+iW1bA5EJRyB5xhu8JY/MyuhRJ7QSiQiMMQDjLbyjADePUebsHP87oecupaL8e27+TctZJeFY/dHG5+JtWis3jb7AW7QHozCeJF18H4G4wTTJJYNVONlj1N40plFJVdl8TWp47UEbStLJEeCAbAH6dIUo94+Hej6oRfyNJpPA== X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 20:YV+l4oLIQuraKOvMFtgo/qe4zBgFnH5NZsPuGNyXBvwmNzXX+q7yxD8Odql8+KSQ1sp7BOwj9IefduK7JkFV7zOIYVekQTxi5DDtV6k2n/bl+URpcDaghElSXSGiFuBfLvHVXE/reB5emwkUU9ftjpMFx1G/IN0dXYjMOIFdu64qUj9/+6BJnoXPVMFIkX0cZFhBWaYHMZqse+jAWWVgiXvfPbhpCKVpEYNj6LT4Qz8MugyGiYn7RAlSsUi0Yw4T1B/nUEpLXwDapqL1po35zXUdrMpBrP6bLunFcBnIUwJSeIi+V4YZuFAQ4P7Y5L4a2KjUq5IAkUaUA4zm6IyVRkaYIi3X4RG8ExW/OgjAcaSZ61XGselUqjJieE+YtyH0JwBd8MxrJJ/3sEK/pro8krNU6M54V2OPwelm1vFt/N1UW6Pj6j+4qK/fFAg+vCi4TdzV3DNK+Z/8i+raqtDBHtBTntiV9NRFLjQAZSYdRymeRuxJn/vb4FKyqdBbC98GTow82SHPG6WVGzOzKaj4YcsQhlzfIZGpUS76M2LLtsZH86Cd5/sL/HNdhbGtB6dpHU7VSjF3oFSLe0aSG8XTd8ubp12Q0zggKLSX1/KlP40= X-Microsoft-Antispam-PRVS: <DM3PR07MB2252FC35E913DC38998F059EEE2B0@DM3PR07MB2252.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(250305191791016)(278428928389397)(22074186197030)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM3PR07MB2252; BCL:0; PCL:0; RULEID:; SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 4:UmHmklek8N6FTwBke0dK4R3YB+DK/3F2/Bx2Uk7lsPkErSFxz9jxsZ/l8MG3AV+DvqrMXqCMkl2FF4DbomcwXX7tXobD+uselYdtjFwB3tBIL9bWan4oEPn+kFQD6/hjs9e++DVpbRdySIWSMr2pLZtZOKR6qQsSG8qPo31S+8CEM/Q/lIVnXhpV2TJlaBiLwhuWYme+4ZAN+waJu0pQeVHWJfLaU89zz1IyWNqJhgMcTC2zDFaY3mucr3nQV/oPpzlXh7dQboDptpxAKdsK/rSKvMj2OBACZyUmVQQZYXBuhPjbw7cRCN4yIszHujijwClv+27gP06gSeUrUQm6uGnSAklZBD69wkIpI/bjVNjZLiPJecrckppJ/MRSjIIGmmdSS7OmMtJfwKimVbu3HSLcfCa+Zj0VKHUJ8+HkNwkCG0y69CnduC6yjarigyNdNrShKaiZ4jaOHI6QP9M7MSzrKxSWWvelhM+7yNFK7zPEG/PNe5CD9Js3jL4mO8+jAJR5tkg4UkkVlh41TvEMng== X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(189002)(199003)(47776003)(50466002)(2950100001)(92566002)(8676002)(76506005)(229853001)(76176999)(15975445007)(48376002)(77096005)(81166006)(7736002)(66066001)(68736007)(33646002)(81156014)(97736004)(50986999)(101416001)(36756003)(42186005)(586003)(50226002)(7846002)(107886002)(3846002)(6116002)(189998001)(106356001)(4326007)(4001430100002)(19580405001)(19580395003)(5003940100001)(105586002)(5001770100001)(2906002)(2004002)(2101003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR07MB2252; H:localhost; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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; DM3PR07MB2252; 23:KCNDRq7WRdy6KzpD4JHJMt7bq8lm2LsmjuDoMrZqW?= =?us-ascii?Q?Q1mLbOt72TfjToISq4GWWml1Wy2pNS7M3BHHfOkDArvkBcJz+o50pkyfBNU7?= =?us-ascii?Q?uW96vT19i/Lz/5jxqMxCyVZc3SK/kXSgeMPZfXqyW4Yrk+sNLj2kIeLYW2q3?= =?us-ascii?Q?ZW70R/6iFwCmRL1jDxd/QTLh1x/inBZpdymrKy4pzJjLKHyI7tsDRVKXGmXJ?= =?us-ascii?Q?OPZ6X7B+bvTWYGbWW0U/DXECXUwjlKCbnP+c8IZ2XHg7xz1Pf2pawUxyZZq2?= =?us-ascii?Q?/Qw3e2zylRC/pKHwSbUUVfVNmxrMAR3PTu8jVKqKRWwx26M3bt6nzrW+rDsX?= =?us-ascii?Q?atedmcb2xvGaeNgsepioQZy/kaFtqRyL+dHvuORApEox0DKSR4f7XHsL2l8K?= =?us-ascii?Q?BjkpD9/o9Y8V661XCLoUlnLBOqGtWbnVRDk3eC8Lvo+JL8EHhxya8ePG5/Ly?= =?us-ascii?Q?jKghdWvUGuLYvI6d3H0ixkmx7ytmbhwHJ0x+66LQj0v4zZEHdMx2ceaBod4r?= =?us-ascii?Q?P8s0i3dIosbsfkLbMjisRK/j5W8gc7ATm5yn4zQU+bCaxQXGGwJhACqBe4kJ?= =?us-ascii?Q?j2+uisvm2mIq2vKp7X3f2ckAln3EDa0QDxTPONDI0HYvjQ+8yeSgUpiwirFD?= =?us-ascii?Q?W+BPd6uTmSN94qV7qPVoxBpUevxZZlygPtU7qjOiE4yJAqkGH2xWY669+TjJ?= =?us-ascii?Q?JKbI2gtOdLIyA4F/QAPDw1ZruktOgd86ruNVDK3PIUoz8rQjmlBBNhChjegL?= =?us-ascii?Q?zRh8/JrCV/aTohNYm5LIzFnFeevyrf8Omxaz/nWFOGBQUd1TYAs9uaG4UU35?= =?us-ascii?Q?cTDjD5z+TmsO+y0aauZrFNOV/P1964lPBKej0hxfAJMMoI8soSbEQCMlPUuz?= =?us-ascii?Q?Eva5yPysxNgGOaVeZLjg+HVv6NnG1Ndz4HWU0b/NDmdLDGDYH0Kp62ehaPL3?= =?us-ascii?Q?EPJqizOkIADicHeQ58oYMQkyNwEPoobdUSz24hNd88vogZR1su63+MV1ANuO?= =?us-ascii?Q?eio9mfVS6zuF9NoI7sOT+MjpQiYdWD+Bm+svatO5pcpTyxUvaGDLlU5gbwXN?= =?us-ascii?Q?nZDlXAYEWihEY/dc320JTfLDc9Tlw+khsdYB+HctuFI4oqrOsCTyf//FqQD9?= =?us-ascii?Q?jrD0Pf3V+qqzfd8+HAwLZdm53X1Yy1okq3oH6nQ47vBvbh7L+36vg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 6:SG7nISV+UNrkkwF8Riz2z3K5MwzAfP7r6RYt1c5TjTTQHalsm3U1vR6lTIJE9LQtUu2T3BIjzURkhIjiF8iVkWu8pxWsC6A8r4i0mz8rJC+L1sgTiIs7NhUYs9jH2XqvenJx3zLp8I4VnWrs8k3z6FdHDKu9sL8g0Woem1n6MkyfVCmxRlEp9fTJNx89Uz/C3xbKPNyXxkDV9MtK3gqP2rLthmFRZEa8pnVb460oaBUNefHWYuqv3z4BGTUxiIdvsvvNMdmFtDhvYjVxZRvwtnZVAV7vrSmjUTnE78FYxqw=; 5:sCQIKMLHmm69DmCSTjIsJVcc/HAHKKPgtx8/fgAB8pzUTh4UsyhAs0JDZnv8VNR9St6HR3PN9rSwvwv3uSqTRnk0205tajXZlAnrLuMTP3ok36fJlBkH7FH/RklTWF2b5+Z6UaR+pwtdHSsosNqlKQ==; 24:cHlhmQzSu/DgTRx8CMdyq9CWqKgd6q+2tfGDKwG+W/h8/sBTXhH26YwDRXithagoaqQnAKDUX+JppYPpD3dSNpKGKICNR7FUnB6OC/ChaQE=; 7:ubPRLkziSaWl4HQecLXPu51wUCbt2sbdo2TkB2oppx1oDF3yZvGg5vKJ2XnNYadk+i1ODlXum3XxIMxJI/4SMsero3fZXqzv/0kRICFGrYS0zggdKXn0aieJzdH4VbBvSVuUFm32FgzFL7wHeWfTtIXpj0PWNrf4khamJ/cg54YpIC6rz/mlkc+VGSLi2t2M8JIC/ZIN6vquFye/ACAsIkcidMyuOSEMX9nVH8X19eEOGbGB7cgXZ/dbVqOBf+cq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 05:07:38.9339 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR07MB2252 |
Commit Message
Yury Norov
June 21, 2016, 5:06 a.m. UTC
From: Andrew Pinski <apinski@cavium.com> NOTE This is an ABI change for AARCH64. If you have some AARCH32 and AARCH64 applications and they both use utmp, one of them will fail due to the use of time_t inside the utmp binary format. This fixes the problem by setting __WORDSIZE_TIME64_COMPAT32. * sysdeps/aarch64/bits/wordsize.h: New file. Signed-off-by: Yury Norov <ynorov@caviumnetworks.com> --- sysdeps/aarch64/bits/wordsize.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 sysdeps/aarch64/bits/wordsize.h
Comments
On 21/06/16 06:06, Yury Norov wrote: > From: Andrew Pinski <apinski@cavium.com> > > NOTE This is an ABI change for AARCH64. > If you have some AARCH32 and AARCH64 applications and they both use > utmp, one of them will fail due to the use of time_t inside the > utmp binary format. > > This fixes the problem by setting __WORDSIZE_TIME64_COMPAT32. i think changing the abi now is not ok. this is BZ 17470 and i think it should be discussed separately from ilp32. if it's possible to detect the utmp file format, that would allow a reasonable fix, the way glibc changes the struct def based on lp64 targets is non-conforming.
On Tue, 21 Jun 2016, Yury Norov wrote: > From: Andrew Pinski <apinski@cavium.com> > > NOTE This is an ABI change for AARCH64. My previous comments <https://sourceware.org/ml/libc-alpha/2014-10/msg00638.html> regarding symbol versioning and warnings in NEWS apply.
On Tue, Jun 21, 2016 at 11:14:54AM +0100, Szabolcs Nagy wrote: > On 21/06/16 06:06, Yury Norov wrote: > > From: Andrew Pinski <apinski@cavium.com> > > > > NOTE This is an ABI change for AARCH64. > > If you have some AARCH32 and AARCH64 applications and they both use > > utmp, one of them will fail due to the use of time_t inside the > > utmp binary format. > > > > This fixes the problem by setting __WORDSIZE_TIME64_COMPAT32. > > i think changing the abi now is not ok. > > this is BZ 17470 and i think it should be discussed separately > from ilp32. > > if it's possible to detect the utmp file format, that would > allow a reasonable fix, the way glibc changes the struct def > based on lp64 targets is non-conforming. Hi Joseph, Szabolcs, I revised it and found that we don't need __WORDSIZE_TIME64_COMPAT32 because ilp32 already has 32-bit time_t. So for now sysdeps/aarch64/bits/wordsize.h is looking like this: #ifdef __LP64__ # define __WORDSIZE 64 #else # define __WORDSIZE 32 # define __WORDSIZE32_SIZE_ULONG 1 # define __WORDSIZE32_PTRDIFF_LONG 1 #endif is it OK? Andrew?
On Wed, Jun 22, 2016 at 9:35 PM, Yury Norov <ynorov@caviumnetworks.com> wrote: > On Tue, Jun 21, 2016 at 11:14:54AM +0100, Szabolcs Nagy wrote: >> On 21/06/16 06:06, Yury Norov wrote: >> > From: Andrew Pinski <apinski@cavium.com> >> > >> > NOTE This is an ABI change for AARCH64. >> > If you have some AARCH32 and AARCH64 applications and they both use >> > utmp, one of them will fail due to the use of time_t inside the >> > utmp binary format. >> > >> > This fixes the problem by setting __WORDSIZE_TIME64_COMPAT32. >> >> i think changing the abi now is not ok. >> >> this is BZ 17470 and i think it should be discussed separately >> from ilp32. >> >> if it's possible to detect the utmp file format, that would >> allow a reasonable fix, the way glibc changes the struct def >> based on lp64 targets is non-conforming. > > Hi Joseph, Szabolcs, > > I revised it and found that we don't need __WORDSIZE_TIME64_COMPAT32 > because ilp32 already has 32-bit time_t. > So for now sysdeps/aarch64/bits/wordsize.h is looking like this: > #ifdef __LP64__ > # define __WORDSIZE 64 > #else > # define __WORDSIZE 32 > # define __WORDSIZE32_SIZE_ULONG 1 > # define __WORDSIZE32_PTRDIFF_LONG 1 > #endif > > is it OK? Andrew? The problem right now is utmp struct is incompatible between ILP32 and LP64 (even incompatible between AARCH32 and AARCH64). So right now if you have two programs which use the utmp file (one aarch64 and one which is aarch32 or one which is ILP32), one which writes the data will not able to read the other one. So if you want aarch64 to be compatible with aarch32, you need to define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and aarch32 to be compatible at all, then we can drop this patch or if you don't want LP64 and ILP32 to be compatible either. So the question now comes do we break AARCH32 or AARCH64 or do we go one step further and fix detecting of which version of the utmp is stored on disk and use that. So we are going to need to the further step for 64bit time_t issues on 32bit ABIs. So do we worry about this now or wait for the rest of the time_t work? Thanks, Andrew
Andrew Pinski <pinskia@gmail.com> writes: > So if you want aarch64 to be compatible with aarch32, you need to > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and > aarch32 to be compatible at all, then we can drop this patch or if you > don't want LP64 and ILP32 to be compatible either. Or go the other way like s390 and use the LP64 layout for ILP32. Andreas.
On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: > Andrew Pinski <pinskia@gmail.com> writes: > > > So if you want aarch64 to be compatible with aarch32, you need to > > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and > > aarch32 to be compatible at all, then we can drop this patch or if you > > don't want LP64 and ILP32 to be compatible either. > > Or go the other way like s390 and use the LP64 layout for ILP32. > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." It was an agreement that we don't fix Y2038 issues specifically, as there will be general fix.
On Thu, Jun 23, 2016 at 12:32 AM, Andreas Schwab <schwab@suse.de> wrote: > Andrew Pinski <pinskia@gmail.com> writes: > >> So if you want aarch64 to be compatible with aarch32, you need to >> define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and >> aarch32 to be compatible at all, then we can drop this patch or if you >> don't want LP64 and ILP32 to be compatible either. > > Or go the other way like s390 and use the LP64 layout for ILP32. That will solve the ILP32 side of things and I am ok with doing that but not it does not solve that right now AARCH32 and AARCH64 are incompatible. You could say AARCH64 LP64 is currently broken because of this incompatible but nobody has complained until now. So the question becomes do we care enough about the incompatibles between AARCH32 and AARCH64 to fix this and go just worry about ILP32 and LP64? Thanks, Andrew > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
On Thu, Jun 23, 2016 at 12:36 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: >> Andrew Pinski <pinskia@gmail.com> writes: >> >> > So if you want aarch64 to be compatible with aarch32, you need to >> > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and >> > aarch32 to be compatible at all, then we can drop this patch or if you >> > don't want LP64 and ILP32 to be compatible either. >> >> Or go the other way like s390 and use the LP64 layout for ILP32. >> >> Andreas. >> >> -- >> Andreas Schwab, SUSE Labs, schwab@suse.de >> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 >> "And now for something completely different." > > It was an agreement that we don't fix Y2038 issues specifically, as > there will be general fix. Except that was the agreement for ILP32 what about AARCH32 and AARCH64 LP64 where is a known issue right now. ARM and AARCH64 maintainers please chime in about this issue. Thanks, Andrew
Andrew Pinski <pinskia@gmail.com> writes: > So the question becomes do we care enough about the incompatibles > between AARCH32 and AARCH64 to fix this and go just worry about ILP32 > and LP64? Some armv8 chips do not implement all of armv7, so how relevant is aarch32 on aarch64? Andreas.
On 06/23/2016 09:36 AM, Yury Norov wrote: > On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: >> Andrew Pinski <pinskia@gmail.com> writes: >> >>> So if you want aarch64 to be compatible with aarch32, you need to >>> define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and >>> aarch32 to be compatible at all, then we can drop this patch or if you >>> don't want LP64 and ILP32 to be compatible either. >> >> Or go the other way like s390 and use the LP64 layout for ILP32. >> >> Andreas. >> >> -- >> Andreas Schwab, SUSE Labs, schwab@suse.de >> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 >> "And now for something completely different." > > It was an agreement that we don't fix Y2038 issues specifically, as > there will be general fix. As far as I understand this, it is not a Y2038 issue because it affects current systems using current dates. It's a separate bug IMHO. Florian
On 06/23/2016 09:56 AM, Andreas Schwab wrote: > Andrew Pinski <pinskia@gmail.com> writes: > >> So the question becomes do we care enough about the incompatibles >> between AARCH32 and AARCH64 to fix this and go just worry about ILP32 >> and LP64? > > Some armv8 chips do not implement all of armv7, so how relevant is > aarch32 on aarch64? I also do not see sufficient justification for this ABI break. Thanks, Florian
On Fri, Jun 24, 2016 at 4:38 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 06/23/2016 09:56 AM, Andreas Schwab wrote: >> >> Andrew Pinski <pinskia@gmail.com> writes: >> >>> So the question becomes do we care enough about the incompatibles >>> between AARCH32 and AARCH64 to fix this and go just worry about ILP32 >>> and LP64? >> >> >> Some armv8 chips do not implement all of armv7, so how relevant is >> aarch32 on aarch64? > > > I also do not see sufficient justification for this ABI break. Yury, Can you patch ILP32 glibc to use 64bit integer for utmp struct? > > Thanks, > Florian >
On Sat, Jun 25, 2016 at 04:26:01PM -0700, Andrew Pinski wrote: > On Fri, Jun 24, 2016 at 4:38 AM, Florian Weimer <fweimer@redhat.com> wrote: > > On 06/23/2016 09:56 AM, Andreas Schwab wrote: > >> > >> Andrew Pinski <pinskia@gmail.com> writes: > >> > >>> So the question becomes do we care enough about the incompatibles > >>> between AARCH32 and AARCH64 to fix this and go just worry about ILP32 > >>> and LP64? > >> > >> > >> Some armv8 chips do not implement all of armv7, so how relevant is > >> aarch32 on aarch64? > > > > > > I also do not see sufficient justification for this ABI break. > > Yury, > Can you patch ILP32 glibc to use 64bit integer for utmp struct? Yes I can. I will send v2 next week with that patch. > > > > > Thanks, > > Florian > >
diff --git a/sysdeps/aarch64/bits/wordsize.h b/sysdeps/aarch64/bits/wordsize.h new file mode 100644 index 0000000..3ecccaa --- /dev/null +++ b/sysdeps/aarch64/bits/wordsize.h @@ -0,0 +1,26 @@ +/* Copyright (C) 2014 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <http://www.gnu.org/licenses/>. */ + +#define __WORDSIZE 64 + +/* LP64 ABI has a 64bit time_t. + This allows aarch32 and AARCH64 applications + both access utmp. */ +#define __WORDSIZE_TIME64_COMPAT32 1 + +/* LP64 use the 64bit system call interface. */ +#define __SYSCALL_WORDSIZE 64