Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

Andrew Pinski
2016-06-23T05:07:44Z

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