[PATCH 2/3] msqid: Provide internal copy of struct __msqid64_ds

Adhemerval Zanella adhemerval.zanella@linaro.org
Fri Nov 13 14:17:28 GMT 2020



On 12/11/2020 19:02, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> On 12/11/2020 12:27, Lukasz Majewski wrote:
>>>> I meant building glibc itself, not user programs using glibc
>>>> provided headers.  It is to ensure that internally 'struct
>>>> timespec' (or any affected struct by 64-bit time) will have 32-bit
>>>> ABI layout for ABIs that supports it since glibc itself includes
>>>> installed headers. 
>>>
>>> Could you elaborate on this?
>>>
>>> I do guess that _TIME_BITS when added to glibc (i.e. when it will be
>>> recognized by "exported" headers) will enable 64 bit time support on
>>> archs with __WORDSIZE=32 (e.g. ARM 32 bit).
>>>
>>> Then, after some time, we will add #define _TIME_BITS 64 at e.g.
>>> features.h (exported) on eligible ports, which would mean that by
>>> default support for 64 bit time is enabled on them.
>>>
>>> Am I correct?  
>>
>> I mean that _TIME_BITS=64 for __WORDSIZE=32 will need to be enable
>> only on testing,
> 
> To be more specific - enabled when some program (user one or tst-* from
> glibc) is compiled (and will be run on Y2038 supporting version of
> glibc).

Yes, similar to what we do for some LFS tests (by defining _FILE_OFFSET_BITS
either on Makefile or on the C file itself).

> 
>> all the glibc objects will need be built with
>> _TIME_BITS=32 
> 
> I would just prefer to not define it when the glibc is built itself. At
> least for my Yocto/OE build I had to explicitly remove the
> -D_TIME_BITS= from system wide CFLAGS.

I don't think we need to explicit define it, a lot of implementations already
expects that default values to correct build the expected objects. What I
meant is we should not support passing _TIME_BITS on the glibc build CFLAGS
itself.

> 
>> so '__time_t' and related structures do not vary
>> depending of the compiler flag (same as support to build glibc itself
>> with _TIME_BITS=64).
> 
> IMHO the __USE_TIME_BITS64 will be set to 1 in (include/features.h ->
> exported as /usr/include/features.h) in some point in time.
> 
> The same approach we now have with __USE_FILE_OFFSET64 in the same file.
> 
>>
>> About making the _TIME_BITS=64 as default, since it implies
>> _FILE_OFFSET_BITS=N we will need to sort some issues first (BZ#14106
>> [1], BZ#15766 [2], BZ#13047 [3] to name the ones I am aware).
> 
> Those issues are not resolved since 2012, so I do guess that those are
> not very urgent or easily solvable.
> 
> The Y2038 support will have consistent name scheme for functions
> aliased (e.g. foo) to 64 bit versions (__foo64 or __foo_time64). If we
> can get away with having the latter exported, so they will not clash, it
> shall be Ok. 

I would guess there are not easily solvable, so I would expect that
the default _TIME_BITS for 32-bit architecture with legacy 32-bit
time_t support would still be '32'.  This unfortunately would require
to be explicit enable on the projects build system and it might not
straightforwards to enable worldwide since we got reports that recent
debian builds still do not enable LFS support on all packages.

I do think we should eventually enable both LFS and 64-bit time as
default for *all* architectures; this solves a lot of possible
issues.

>>
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=14106
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=15766 
>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=13047

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201113/29ec3fc9/attachment.sig>


More information about the Libc-alpha mailing list