diff mbox

[01/27,AARCH64] Fix utmp struct for compatibility reasons.

Message ID 1466485631-3532-2-git-send-email-ynorov@caviumnetworks.com
State New, archived
Headers

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

Szabolcs Nagy June 21, 2016, 10:14 a.m. UTC | #1 
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.
Joseph Myers June 21, 2016, 10:24 a.m. UTC | #2 
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.
Yury Norov June 23, 2016, 4:35 a.m. UTC | #3 
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?
Andrew Pinski June 23, 2016, 5:07 a.m. UTC | #4 
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
Andreas Schwab June 23, 2016, 7:32 a.m. UTC | #5 
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.
Yury Norov June 23, 2016, 7:36 a.m. UTC | #6 
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.
Andrew Pinski June 23, 2016, 7:36 a.m. UTC | #7 
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."
Andrew Pinski June 23, 2016, 7:37 a.m. UTC | #8 
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
Andreas Schwab June 23, 2016, 7:56 a.m. UTC | #9 
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.
Florian Weimer June 24, 2016, 11:33 a.m. UTC | #10 
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
Florian Weimer June 24, 2016, 11:38 a.m. UTC | #11 
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
Andrew Pinski June 25, 2016, 11:26 p.m. UTC | #12 
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
>
Yury Norov June 26, 2016, 6:13 a.m. UTC | #13 
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 mbox

Patch

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