Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
Hi Vineet, > On 7/7/20 12:21 AM, Lukasz Majewski wrote: > >> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built > >> (instead generic variant is). How do I override the generic fiel to > >> be built instead ? > > The futimes.c from sysdeps/unix/sysv/linux/ shall be built. > > > > The futimes.c is defined in following locations: > > y2038-glibc/misc > > y2038-glibc/sysdeps/unix/sysv/linux > > y2038-glibc/sysdeps/mach/hurd > > > > The first one is a stub. The last one is for hurd. > > ARC shall use the middle one as well. > > It seems I mixed up the various *utime* files. > Following are currently building for ARC > > sysdeps/unix/sysv/linux/generic/futimesat.c > sysdeps/unix/sysv/linux/generic/utimes.c#2 > > sysdeps/unix/sysv/linux/futimes.c > sysdeps/unix/sysv/linux/futimens.c > sysdeps/unix/sysv/linux/utimensat.c > > The issue is generic/utimes.c > > Is that the right file to build. If yes then it needs fixing as it > expects __NR_utimensat (and thus require the aliasing hack in ARC > sysdep.h) > > #define __NR_utimensat__NR_utimensat_time6 > > P.S. I know glibc wiki has a bunch of pages (from Arnd?) for the > y2038 support. This wiki page was developed by Albert Aribaud and shall give you a grasp about the work needed for Y2038 conversion. However, it is now outdated as we already made some progress. The most accurate list of supported/converted syscalls can be found here: https://github.com/lmajewski/y2038_glibc/commit/b94a7f1126dc5bd652ba3a856753e85e48a6e845 and the most up to date development branch for Y2038 conversion: https://github.com/lmajewski/y2038_glibc/commits/y2038_edge (I've sent yesterday a patch series to convert futex to futex_time64). > Are there other (newer) docs which explain the whole > song and dance or is it the usual RTFC. > > > When I'm in doubt (or when for example code is auto generated to > > wrap a syscall) I do use > > https://github.com/lmajewski/meta-y2038/blob/master/README > > > > with gdb to check which function is called. Maybe it would help you > > too? > > Yeah. I typically use build logs to see which exact file is built and > then objdump to corroborate. Ok. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpitzzOBHX_P.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
On Mon, 6 Jul 2020 22:58:27 +
Vineet Gupta wrote:
> Hi Lukasz,
>
> On 2/17/20 5:17 AM, Lukasz Majewski wrote:
> > This patch provides new __futimes64 explicit 64 bit function for
> > setting file's 64 bit attributes for access and modification time
> > (by specifying file descriptor number).
> >
> > Internally, the __utimensat64_helper function is used. This patch
> > is necessary for having architectures with __WORDSIZE == 32 Y2038
> > safe.
> >
> > Moreover, a 32 bit version - __futimes has been refactored to
> > internally use __futimes64.
> >
> > The __futimes is now supposed to be used on systems still
> > supporting 32 bit time (__TIMESIZE != 64) - hence the necessary
> > conversion of struct timeval to 64 bit struct __timeval64.
> >
> > The check if struct timevals' usec fields are in the range between
> > 0 and 100 has been removed as Linux kernel performs it
> > internally in the implementation of utimensat (the conversion
> > between struct __timeval64 and __timespec64 is not relevant for
> > this particular check).
> >
> > Last but not least, checks for tvp{64} not being NULL have been
> > preserved from the original code as some legacy user space programs
> > may rely on it.
> >
> > Build tests:
> > ./src/scripts/build-many-glibcs.py glibcs
> >
> > Run-time tests:
> > - Run specific tests on ARM/x86 32bit systems (qemu):
> > https://github.com/lmajewski/meta-y2038 and run tests:
> > https://github.com/lmajewski/y2038-tests/commits/master
> >
> > Above tests were performed with Y2038 redirection applied as well
> > as without to test the proper usage of both __futimes64 and
> > __futimes. ---
> > include/time.h| 3 +++
> > sysdeps/unix/sysv/linux/futimes.c | 42
> > +--
>
> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built
> (instead generic variant is). How do I override the generic fiel to
> be built instead ?
The futimes.c from sysdeps/unix/sysv/linux/ shall be built.
The futimes.c is defined in following locations:
y2038-glibc/misc
y2038-glibc/sysdeps/unix/sysv/linux
y2038-glibc/sysdeps/mach/hurd
The first one is a stub. The last one is for hurd.
ARC shall use the middle one as well.
When I'm in doubt (or when for example code is auto generated to wrap a
syscall) I do use
https://github.com/lmajewski/meta-y2038/blob/master/README
with gdb to check which function is called. Maybe it would help you too?
>
> > 2 files changed, 26 insertions(+), 19 deletions(-)
> >
> > diff --git a/include/time.h b/include/time.h
> > index b81ecd5e6e..c24066bf3a 100644
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -210,8 +210,11 @@ extern int __utimensat64_helper (int fd, const
> > char *file, libc_hidden_proto (__utimensat64_helper);
> >
> > #if __TIMESIZE == 64
> > +# define __futimes64 __futimes
> > # define __futimens64 __futimens
> > #else
> > +extern int __futimes64 (int fd, const struct __timeval64 tvp64[2]);
> > +libc_hidden_proto (__futimes64);
> > extern int __futimens64 (int fd, const struct __timespec64 tsp[2]);
> > libc_hidden_proto (__futimens64);
> > #endif
> > diff --git a/sysdeps/unix/sysv/linux/futimes.c
> > b/sysdeps/unix/sysv/linux/futimes.c index 4bea864470..21b41e4138
> > 100644 --- a/sysdeps/unix/sysv/linux/futimes.c
> > +++ b/sysdeps/unix/sysv/linux/futimes.c
> > @@ -17,35 +17,39 @@
> > <https://www.gnu.org/licenses/>. */
> >
> > #include
> > -#include
> > -#include
> > #include
> > -#include
> > -#include
> > -#include <_itoa.h>
> > -#include
> > -
> >
> > /* Change the access time of the file associated with FD to TVP[0]
> > and
> > - the modification time of FILE to TVP[1].
> > + the modification time of FILE to TVP[1]. */
> > +int
> > +__futimes64 (int fd, const struct __timeval64 tvp64[2])
> > +{
> > + /* The utimensat system call expects timespec not timeval. */
> > + struct __timespec64 ts64[2];
> > + if (tvp64 != NULL)
> > +{
> > + ts64[0] = timeval64_to_timespec64 (tvp64[0]);
> > + ts64[1] = timeval64_to_timespec64 (tvp64[1]);
> > +}
> > +
> > + return __utimensat64_helper (fd, NULL, tvp64 ? [0] : NULL,
> > 0); +}
> > +
> > +#if __TIMESIZE != 64
> > +libc_hidden_def (__futimes64)
> >
> > - Starting with 2.6.22 the Linux kernel has the utimensat syscall
> > which
> > - can be used to
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph, > On Wed, 26 Feb 2020, Lukasz Majewski wrote: > > > > > hidden_def (__mq_timedsend) > > > > weak_alias (__mq_timedsend, mq_timedsend) [**] > > > > hidden_weak (mq_timedsend) > > > > > > If you have lib_hidden_weak note you also need a > > > corresponding lib_hidden_proto, for the name of the weak > > > alias. But you probably don't need to have lib_hidden* for > > > the weak alias at all, just make sure internal calls use the > > > internal name. > > > > As fair as I can tell the weak_alias () is necessary for correct > > operation of mq_timedsend when external programs call it. > > I wasn't commenting on the weak_alias call, but on the hidden_weak > one. Ach... indeed - sorry for misunderstanding. > > If you have hidden_weak (mq_timedsend), you also need > lib_hidden_proto (mq_timedsend) in the internal header (and > vice versa, hidden_proto implies you need hidden_weak). > > You don't need hidden_weak (mq_timedsend) unless there is an > *internal call to mq_timedsend from within the same library that > defines it*. > > Since such an internal call could just use __mq_timedsend instead, > you probably don't need hidden_weak / hidden_proto for mq_timedsend. > > (If you don't have an internal call to __mq_timedsend, you don't need > the hidden_* for that name either.) > Thanks for the explanation. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpJmlc3KmuVy.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph,
> On Tue, 25 Feb 2020, Lukasz Majewski wrote:
>
> > Lets consider for example __mq_timedsend_time64.
> >
> > With lib_hidden_def/proto kept (NOT removed as in [1]):
> > GDB:
> > __GI___mq_timedsend_time64 [*]
> >
> > (No build errors, linking with test setup works as expected).
>
> What is the actual testcase, and the exact command line used to
> compile it?
The test case is a separate program [1] compiled with [2] (the
test_y2038 make target)
The glibc under test is installed on rootfs run by QEMU for ARM.
The lack of redirection, when I keep lib_hidden_proto/
lib_hidden_def for __mq_timedsend_time64, is seen when I debug
with GDB the 'test_y2038' program.
The glibc compiles correctly.
>
> _TIME_BITS=64 redirection is only relevant for programs built with
> glibc, using the installed headers - not for building glibc itself.
>
> lib_hidden_proto is only relevant for building glibc, with its
> internal headers - not for programs built with glibc.
It seems like not removing lib_hidden_proto/ lib_hidden_def
for __mq_timedsend_time64 in glibc sources prevents the redirection on
installed glibc / headers when 'test_y2038' program is run.
>
> If you're talking about a glibc testcase, such tests should be in
> tests not tests-internal, so _ISOMAC is defined when they are built,
> so the glibc internal headers just wrap the public ones without
> defining anything else. In particular, the asm redirections from
> public headers should be in effect when tests are compiled, but not
> the lib_hidden_proto redirections (but even for internal tests,
> lib_hidden_proto shouldn't do anything because the build
> process knows they are tests not part of libc).
Unfortunately, mine Y2038 tests are a set of compiled programs (it is a
'legacy' code) and have nothing in common with glibc test suite.
The workflow is as follows (standard Yocto/OE):
1. Built the glibc and prepare "package" for other recipes.
2. For tests get the glibc "package" as a prerequisite. Use its
exported headers and libraries to build tests. Prepare test "package"
3. Install both above packages to rootfs
4. Run the rootfs with QEMU.
>
> You should look at the preprocessed source from building the test
> with -save-temps and find out why the asm redirection from the public
> header isn't being effective (or if it is effective in the .o file
> for the test, look at what happens afterwards in glibc). Since
> lib_hidden_proto should not be called in the parts of headers
> included when building a test, its presence or absence should have no
> effect on the preprocessed source of the test.
Ok. I will dig the object files and generated temp files.
>
> > hidden_def (__mq_timedsend)
> > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > hidden_weak (mq_timedsend)
>
> If you have lib_hidden_weak note you also need a corresponding
> lib_hidden_proto, for the name of the weak alias. But you
> probably don't need to have lib_hidden* for the weak alias at
> all, just make sure internal calls use the internal name.
As fair as I can tell the weak_alias () is necessary for correct
operation of mq_timedsend when external programs call it.
Glibc internally defines __mq_timedsend (also for archs with
__WORDSIZE==64), but it exports mq_timedsend (and user space programs
call it). One needs an alias (at least a weak one) between mq_timedsend
and __mq_timedsend{_time}. Am I correct?
>
Links:
[1] -
https://github.com/lmajewski/y2038-tests/blob/master/test_mq_timedsend.c#L25
[2] - https://github.com/lmajewski/y2038-tests/blob/master/Makefile
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpeaDpaxTvWW.pgp
Description: OpenPGP digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph,
Thanks for the detailed explanation.
> On Mon, 24 Feb 2020, Lukasz Majewski wrote:
>
> > I'm probably not aware of something - but as done in the following
> > patch:
> >
> > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> >
> > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > proper symbols visible when I do want to use redirections.
>
> You'll need to explain the actual problem you see, because
> lib_hidden_proto / lib_hidden_def are correct for any
> symbol that satisfies both of the following properties: (a) it is
> exported from shared lib (whether at a public symbol version or
> version GLIBC_PRIVATE) and (b) it is also used within the library
> that defines it. They are useless but harmless for other symbols.
>
Lets consider for example __mq_timedsend_time64.
With lib_hidden_def/proto kept (NOT removed as in [1]):
GDB:
__GI___mq_timedsend_time64 [*]
(No build errors, linking with test setup works as expected).
(gdb) bt
#0 __libc_do_syscall ()
at../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
#1 0x76fc2696 in __GI___mq_timedsend_time64 (..)
at../sysdeps/unix/sysv/linux/mq_timedsend.c:33
#2 0x76fc271a in __GI___mq_timedsend (..)
at../sysdeps/unix/sysv/linux/mq_timedsend.c:69
#3 0x76fc2668 in mq_send () at ../sysdeps/unix/sysv/linux/mq_send.c:30
The problem is that __mq_timedsend (32 bit version) is called first -
this means that the redirection for _TIME_BITS==64 (which would call
__mq_timedsend_time64) is not working.
With lib_hidden_def/proto removed (as it is now at [1])
#0 __mq_timedsend_time64 (..) at../sysdeps/unix/sysv/linux/mq_timedsend.c33
#1 0x00402bb0 in test_mq_timedsend_onqueue (q=3)
at test_mq_timedsend.c:25
#2 0x00402f28 in test_mq_timedsend () at test_mq_timedsend.c:130
The redirection for _TIME_BITS==64 works as expected.
The structure of time conversion patches (details in [2]):
@ include/time.h
#if __TIMESIZE == 64
# define __mq_timedsend_time64 __mq_timedsend
#else
# include
extern int __mq_timedsend_time64 (...);
librt_hidden_proto (__mq_timedsend_time64)
#endif
@sysdeps/unix/sysv/linux/mq_timedsend.c
int __mq_timedsend_time64 (...)
{
}
#if __TIMESIZE != 64
librt_hidden_def (__mq_timedsend_time64)
int __mq_timedsend (..)
{
}
#endif
hidden_def (__mq_timedsend)
weak_alias (__mq_timedsend, mq_timedsend) [**]
hidden_weak (mq_timedsend)
It looks to me like the [**] weak_alias () here is the problem as it
does the aliasing for name, which shall be redirected to
__mq_timedsend_time64.
However, when I remove the line [**] - I do see the error:
| In file included from :
| ./../include/libc-symbols.h:552:33: error: '__EI_mq_timedsend'
aliased to undefined symbol '__GI_mq_timedsend'
> lib_hidden_proto / lib_hidden_def always need to be used
> together, and always need to have matching the name of the
> shared library with the symbol. In C code, lib_hidden_proto
> causes the function, for both definition and calls, to be redirected
> to an internal, hidden-visibility alias, while lib_hidden_def
> then adds back the exported name as a non-hidden alias to cause it to
> be exported from the shared library in question.
I was not aware of the lib_hidden_def () role to re-export the
symbols again. Thanks for pointing this out.
>
> It's true that the redirection from lib_hidden_proto doesn't
> work when there is another redirection for the same symbol in effect,
Please correct me if I'm wrong, but from the above code snippet it
looks like we do have (when _TIME_SIZE==64 is defined):
librt_hidden_proto (__mq_timedsend_time64)
librt_hidden_def (__mq_timedsend_time64)
hidden_def (__mq_timedsend)
weak_alias (__mq_timedsend, mq_timedsend)
And in exported headers:
# ifdef __USE_TIME_BITS64
# if defined(__REDIRECT)
extern int __REDIRECT (mq_timedsend, (..),
__mq_timedsend_time64);
# else
# define mq_timedsend __mq_timedsend_time64
# endif
# endif
Unfortunately, the final redirection for mq_timedsend symbol is to
__mq_timedsend, not __mq_timedsend_time64.
> but that should not be a concern here (there should be no reason to
> have an asm redirection from __mq_timedreceive_time64 to another
> name, for example).
>
Question:
[*] - If I may ask - the __GI_ prefix is for glibc internal symbol? And
in the same vein __EI_ is for external one?
Links:
[1] -
https://github.com/lmajewski/y2038_glibc/commit/06fe0342696d7c6fe6115f825052fb07bb609216
[2] - https://patchwork.ozlabs.org/patch/1237939/
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpX27LgpHnPW.pgp
Description: OpenPGP digital signature
_
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Dear All,
> On Mon, 24 Feb 2020 11:42:23 +0100
> Andreas Schwab wrote:
>
> > On Feb 24 2020, Lukasz Majewski wrote:
> >
> > > On Mon, 24 Feb 2020 11:23:51 +0100
> > > Andreas Schwab wrote:
> > >
> > >> On Feb 24 2020, Lukasz Majewski wrote:
> > >>
> > >> > If I add those functions as hidden_alias then those would be
> > >> > accessible inside glibc without PLT, but will not be exported
> > >> > (and redirection for Y2038 will not work).
> > >>
> > >> They aren't? PLT avoidance is about internal references, and
> > >> uses a different name then the exported sybmol.
> > >>
> > >
> > > I'm probably not aware of something - but as done in the following
> > > patch:
> > >
> > > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> > >
> > > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > > proper symbols visible when I do want to use redirections.
> >
> > You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed
> > to be used by public interfaces. All public interfaces need to use
> > official versioned symbols.
> >
>
> I've put those symbols to GLIBC_PRIVATE as up till now many more
> functions in glibc needs conversion to support 64 bit time. I need
> exported symbols to test if the redirection (and Y2038 safeness on ARM
> in general) works.
>
> I also do guess that when we will be heading to expose _TIME_BITS==64
> to outside word I would need to add:
>
> GLIBC_2.3X {
> clock_settime64;
^^^ - it should be __clock_settime64
> }
>
> for clock_settime64
>
> and then:
>
> #ifdef __USE_TIME_BITS64
> # if defined(__REDIRECT_NTH)
> extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const
> struct timespec *__tp), clock_settime64);
^^ - __clock_settime64
> # else
> # define clock_settime clock_settime64
^^ - __clock_settime64
> # endif
> #endif
>
>
> Am I correct ?
>
> > Andreas.
> >
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpHkYz6RiSxb.pgp
Description: OpenPGP digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
On Mon, 24 Feb 2020 11:42:23 +0100
Andreas Schwab wrote:
> On Feb 24 2020, Lukasz Majewski wrote:
>
> > On Mon, 24 Feb 2020 11:23:51 +0100
> > Andreas Schwab wrote:
> >
> >> On Feb 24 2020, Lukasz Majewski wrote:
> >>
> >> > If I add those functions as hidden_alias then those would be
> >> > accessible inside glibc without PLT, but will not be exported
> >> > (and redirection for Y2038 will not work).
> >>
> >> They aren't? PLT avoidance is about internal references, and uses
> >> a different name then the exported sybmol.
> >>
> >
> > I'm probably not aware of something - but as done in the following
> > patch:
> >
> > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> >
> > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > proper symbols visible when I do want to use redirections.
>
> You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed to
> be used by public interfaces. All public interfaces need to use
> official versioned symbols.
>
I've put those symbols to GLIBC_PRIVATE as up till now many more
functions in glibc needs conversion to support 64 bit time. I need
exported symbols to test if the redirection (and Y2038 safeness on ARM
in general) works.
I also do guess that when we will be heading to expose _TIME_BITS==64
to outside word I would need to add:
GLIBC_2.3X {
clock_settime64;
}
for clock_settime64
and then:
#ifdef __USE_TIME_BITS64
# if defined(__REDIRECT_NTH)
extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const
struct timespec *__tp), clock_settime64);
# else
# define clock_settime clock_settime64
# endif
#endif
Am I correct ?
> Andreas.
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpNdwLSQ8dL6.pgp
Description: OpenPGP digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
On Mon, 24 Feb 2020 11:23:51 +0100 Andreas Schwab wrote: > On Feb 24 2020, Lukasz Majewski wrote: > > > If I add those functions as hidden_alias then those would be > > accessible inside glibc without PLT, but will not be exported (and > > redirection for Y2038 will not work). > > They aren't? PLT avoidance is about internal references, and uses a > different name then the exported sybmol. > I'm probably not aware of something - but as done in the following patch: https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9 I do need to remove librt_hidden_proto / librt_hidden_def to have proper symbols visible when I do want to use redirections. (the same issue is with libc_hidden_proto / libc_hidden_def): https://github.com/lmajewski/y2038_glibc/commit/361f05e38c0d5c6673914af330e766c2ed4f9a8a > Andreas. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpEZIRP92v97.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Andreas, > On Feb 24 2020, Lukasz Majewski wrote: > > >> elf/check-localplt complains about the newly added symbols > >> > >> Extra PLT reference: libc.so: __lutimes64 > >> Extra PLT reference: libc.so: __wait4_time64 > >> Extra PLT reference: libc.so: __setitimer64 > >> Extra PLT reference: libc.so: __utime64 > >> Extra PLT reference: libc.so: __timerfd_gettime64 > >> Extra PLT reference: libc.so: __clock_settime64 > >> Extra PLT reference: libc.so: __utimes64 > >> Extra PLT reference: libc.so: __gettimeofday64 > >> Extra PLT reference: libc.so: __clock_gettime64 > >> Extra PLT reference: libc.so: __futimesat64 > >> Extra PLT reference: libc.so: __clock_getres64 > >> Extra PLT reference: libc.so: __futimes64 > >> Extra PLT reference: libc.so: __futimens64 > >> Extra PLT reference: libc.so: __utimensat64 > >> Extra PLT reference: libc.so: __getrusage64 > >> Extra PLT reference: libc.so: __timespec_get64 > >> Extra PLT reference: libc.so: __getitimer64 > >> Extra PLT reference: libc.so: __ppoll64 > >> Extra PLT reference: libc.so: __timerfd_settime64 > >> Extra PLT reference: libc.so: __clock_nanosleep_time64 > >> Extra PLT reference: libc.so: __sched_rr_get_interval64 > >> Extra PLT reference: libc.so: __settimeofday64 > >> Extra PLT reference: librt.so: __timer_gettime64 > >> Extra PLT reference: librt.so: __mq_timedreceive_time64 > >> Extra PLT reference: librt.so: __mq_timedsend_time64 > >> Extra PLT reference: librt.so: __timer_settime64 > >> > > > > The above problems are somewhat expected. Those are redirected > > symbols, which are exported as GLIBC_PRIVATE in several Versions > > files. > > > > I do guess that we will have a consensus if we add those as a > > "normal" exported symbols or keep them "private". > > They need to grow hidden aliases. Could you explain it a bit more? If I add those functions as hidden_alias then those would be accessible inside glibc without PLT, but will not be exported (and redirection for Y2038 will not work). > > Andreas. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpcMl8uiOdmY.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > wrote: > > > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge > > I tried packaging this into a .deb package for use with rebootstrap, > but ran into a couple of test failures from glibc itself, when > testing the i386 version while running on an older x86_64 kernel > (4.15): Thanks for testing. I do use 4.19 as the oldest kernel. > > +-+ > | Encountered regressions that don't match expected failures. > | > +-+ > FAIL: elf/check-localplt FAIL: nptl/tst-cancel19 > FAIL: rt/tst-mqueue2 > make: *** [debian/rules.d/build.mk:116: > /home/arnd/glibc-2.31/stamp-dir/check_i386] Error 1 > > elf/check-localplt complains about the newly added symbols > > Extra PLT reference: libc.so: __lutimes64 > Extra PLT reference: libc.so: __wait4_time64 > Extra PLT reference: libc.so: __setitimer64 > Extra PLT reference: libc.so: __utime64 > Extra PLT reference: libc.so: __timerfd_gettime64 > Extra PLT reference: libc.so: __clock_settime64 > Extra PLT reference: libc.so: __utimes64 > Extra PLT reference: libc.so: __gettimeofday64 > Extra PLT reference: libc.so: __clock_gettime64 > Extra PLT reference: libc.so: __futimesat64 > Extra PLT reference: libc.so: __clock_getres64 > Extra PLT reference: libc.so: __futimes64 > Extra PLT reference: libc.so: __futimens64 > Extra PLT reference: libc.so: __utimensat64 > Extra PLT reference: libc.so: __getrusage64 > Extra PLT reference: libc.so: __timespec_get64 > Extra PLT reference: libc.so: __getitimer64 > Extra PLT reference: libc.so: __ppoll64 > Extra PLT reference: libc.so: __timerfd_settime64 > Extra PLT reference: libc.so: __clock_nanosleep_time64 > Extra PLT reference: libc.so: __sched_rr_get_interval64 > Extra PLT reference: libc.so: __settimeofday64 > Extra PLT reference: librt.so: __timer_gettime64 > Extra PLT reference: librt.so: __mq_timedreceive_time64 > Extra PLT reference: librt.so: __mq_timedsend_time64 > Extra PLT reference: librt.so: __timer_settime64 > The above problems are somewhat expected. Those are redirected symbols, which are exported as GLIBC_PRIVATE in several Versions files. I do guess that we will have a consensus if we add those as a "normal" exported symbols or keep them "private". > which seems a bug in the test suite. The other two get a segfault > that I have not debugged, but I guess this is likely a problem in your > patches. Have you seen the same thing? I only do run the full (including full test suite) glibc-many-build (and my Y2038 tests) on the patches which I post to glibc-alpha. The Y2038 changes I do test manually if they work as expected - but I do not run yet the (full) test suites on it, as first _all_ glibc functions needs to be converted before _TIME_BITS=64 is added. The issue is probably with the redirection code. I will look on them soon. > >Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpHEzFhtTVZ3.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, > On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote: > > > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski > > > wrote: > > > > > I do see two approaches here: > > > > 1. In glibc: > > > > When -D_TIME_BITS=64 is set - redirections are enabled for syscall > > wrappers; for example __clock_settime64 is used instead of > > __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime). > > > > The latter is guarded by #ifdef __TIMESIZE != 64 so we could change > > mechanically that __clock_settime returns -1 and sets errno to > > -ENOTSUPP > > What I meant is to remove the __clock_settime function from the > library entirely to cause a link failure. I suppose replacing most > "__TIMESIZE != 64" with '0' would do that. Ideally I'd just set I think that replacing "__TIMESIZE != 64" with '0' would be the simplest option. > __TIMESIZE to 64, but doing that would make the ABI incompatible > with mainline glibc. > > > 2. In kernel - return -ENOTSUPP when clock_settime syscall instead > > of clock_settime64 is invoked. > > We already have that with CONFIG_COMPAT_32BIT_TIME, but > at the moment I think that still breaks glibc's usage of __NR_futex, > and a compile-time error is always better than a runtime error, > as it's easier to catch them reliably Ok. > > Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpEzWz1l8LvV.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote: > > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > > > wrote: > > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > > > Are there any glibc issues that prevent it > > > > > from working correctly, > > > > > > > > I think that the glibc wrappers for most important syscalls are > > > > now converted. > > > > > > > > What is missing: > > > > > > > > - NTPL (threads) > > > > - stat > > > > > > Do you mean that code using these will fail to work correctly with > > > -D_TIME_BITS=64 at the moment, or that the interfaces are there > > > but they are not y2038 safe? > > > > For ARM32 (branch [2]): > > > > - Without -D_TIME_BITS=64 defined during compilation (as we do have > > now) the glibc is fully functional, but when you set date after > > 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) > > in the user space programs (after calling e.g. 'date'). > > I'd actually consider intentionally breaking this for a Debian > bootstrap, at least initially, so that any application that > accidentally gets built without -D_TIME_BITS=64 runs into a build or > link failure. I do see two approaches here: 1. In glibc: When -D_TIME_BITS=64 is set - redirections are enabled for syscall wrappers; for example __clock_settime64 is used instead of __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime). The latter is guarded by #ifdef __TIMESIZE != 64 so we could change mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP 2. In kernel - return -ENOTSUPP when clock_settime syscall instead of clock_settime64 is invoked. > > > - With -D_TIME_BITS=64 set during compilation - and using branch > > [2] - syscalls listed in [1] will provide correct date after Y2038 > > 32 bit overflow. Other (i.e. not converted ones) will use overflow > > date (1901 year). The glibc will also be fully functional up till > > Y2038 overflow. > > Ok. > > > > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have > > > > some basic tests [4], but this may be not enough. > > > > > > This is probably something where debian-rebootstrap could help, > > > as building and testing more user space packages will excercise > > > additional code paths in glibc as well. > > > > Yes this _could_ help. Do you have any tutorial/howto similar to one > > from [4]? > > Not sure, maybe Helmut has some references. > > > > There is also some work > > > in Linaro to ensure that LTP tests the low-level syscall > > > interfaces in both the time32 and time64 variants. > > > > Interesting. Is this work now publicly available? > > I think this is currently in the planning stage, but once patches > are available, they would be posted to the ltp mailing list. Viresh > should have more details on this. > >Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpR7yQ3H4hUC.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > wrote: > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > > > > Would it be possible to take a snapshot of your glibc tree > > > > The description of the status of Y2038 supporting glibc on ARM 32 > > can be found here [1]. > > > > The most recent patches for Y2038 supporting glibc can be always > > found in the 'y2038_edge' branch [2]. > > Ok. > > > > and start testing this out with debian-rebootstrap [1]? > > > > I've been using OE/Yocto for testing as it allows building glibc > > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and > > mips - but not tested). > >... > > However, I did not yet tried debian-rebootstrap. I will look if this > > can be reused as well. > > The reason I'm asking about debian-rebootstrap is less about testing > glibc itself than about testing the rest of user space to figure out > better what needs to be done when rebuilding with _TIME_BITS=64, and > to start fixing more upstream packages, with the hope of having enough > of it done in time for the Debian 11 release. Ok. I see. Thanks for the information. Validating the packages was one of the reasons to move from some custom made test images/setup to Yocto/OE (as it is very close to customers needs). > > > > Are there any glibc issues that prevent it from working > > > correctly, > > > > I think that the glibc wrappers for most important syscalls are now > > converted. > > > > What is missing: > > > > - NTPL (threads) > > - stat > > Do you mean that code using these will fail to work correctly with > -D_TIME_BITS=64 at the moment, or that the interfaces are there > but they are not y2038 safe? For ARM32 (branch [2]): - Without -D_TIME_BITS=64 defined during compilation (as we do have now) the glibc is fully functional, but when you set date after 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in the user space programs (after calling e.g. 'date'). - With -D_TIME_BITS=64 set during compilation - and using branch [2] - syscalls listed in [1] will provide correct date after Y2038 32 bit overflow. Other (i.e. not converted ones) will use overflow date (1901 year). The glibc will also be fully functional up till Y2038 overflow. > Without pthreads or stat, we probably > wouldn't get too far in rebootstrap, but if the interfaces are there > and mostly work, then we don't need to rely on them being > y2038-safe just yet. According to my above statement the second assumption is correct. > An obvious next step would be to run the > resulting code with the RTC set 20 years ahead, and that requires > it all to work. Yes. This is what I do for the test setup [3]. I do use clock_settime syscall (now it is working correctly) or just 'date' from user space. > > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have > > some basic tests [4], but this may be not enough. > > This is probably something where debian-rebootstrap could help, > as building and testing more user space packages will excercise > additional code paths in glibc as well. Yes this _could_ help. Do you have any tutorial/howto similar to one from [4]? I also think that some tests from debian-rebootstrap could be moved to glibc test framework (test suite). For example tests for clock_settime/gettime/nanosleep/ etc. In that way the glibc-many-build.py would run those tests for all supported ports. Then the debian-rebootstrap could test for more sophisticated bugs (like dependencies between syscalls, etc). > There is also some work > in Linaro to ensure that LTP tests the low-level syscall interfaces > in both the time32 and time64 variants. Interesting. Is this work now publicly available? > > Arnd Links: [1] - https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1 [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge [3] - https://github.com/lmajewski/y2038-tests [4] - https://github.com/lmajewski/meta-y2038/blob/master/README Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpaCbOAfMPkX.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
Hi Arnd, Joseph, > On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers > wrote: > > > > On Thu, 20 Feb 2020, Vineet Gupta wrote: > > > > > The first 4 will need more work as sym aliasing like > > > strong_alias (__xstat64, __xstat) > > > > > > will be needed in those ARM files (which in turn use i386). > > > > The situation for Arm is fundamentally different from that for ARC. > > > > For ARC, you only need a single public stat structure (using 64-bit > > times and offsets). > > > > For Arm, a third public stat structure will need to be added > > alongside the existing two, initially used internally in > > 64-bit-time stat functions that aren't exported from glibc, > > eventually to be used with _TIME_BITS=64 with the 64-bit-time stat > > interfaces exported once all the _TIME_BITS=64 interfaces are > > ready. > > But surely that structure layout would be the same on ARM and ARC > as well as all other 32-bit architectures with _TIME_BITS=64, right? > For ARM32 stat case (current): ./io/stat.c -> __xstat -> ./sysdeps/unix/sysv/linux/xstat64.c and then struct stat64 buf is filled by the kernel. The generic idea (which requires converting ./sysdeps/unix/sysv/linux/xstat64.c) would be to use statx always in glibc instead of stat* syscalls (as it is done in sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c) To do that we do need in-glibc internal new type - namely struct stat64_time64 which would have always: __time64_t st_atime; (and st_mtime, st_ctime). instead of __time_t st_atime; and also introduce __cp_stat64_time64_statx along with __cp_stat64_statx as struct statx inherently support 64 bit time via struct statx_timestamp even on 32 bit archs. IMHO using statx as widely as possible in glibc is the easiest way to convert stat* and friends functions to support Y2038. > What's wrong with having a single implementation for the most > recent set of stat syscalls, with the older variants being only > compiled for architectures that need them to support _TIME_BITS=32 > and/or _FILE_OFFSET_BITS=32? > > Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpbtTcjFBssH.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > wrote: > > > On 2/14/20 2:39 PM, Alistair Francis wrote: > > > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers > > > An the reason this all works on RISCV is that your kernel doesn't > > > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses > > > the statx call which does itemized copy and would work fine when > > > copying from 32-bits time (in kernel) to 64-bits container in > > > glibc. Is this is right understanding or am I missing something > > > here. > > > > > > How do I build a latest RISCV 32-bit kernel + userland - do you > > > have a buildroot branch somewhere that I can build / test with > > > qemu ? > > > > Maybe a bit off topic - there is such QEMU and Yocto/OE based test > > sandbox for ARM32: > > > > https://github.com/lmajewski/meta-y2038 > > > > (the README provides steps for setup). > > (continuing off-topic, with debian-arm and Helmut on Cc) > > Would it be possible to take a snapshot of your glibc tree The description of the status of Y2038 supporting glibc on ARM 32 can be found here [1]. The most recent patches for Y2038 supporting glibc can be always found in the 'y2038_edge' branch [2]. I also do have a 'warrior' based glibc branch [3], which is a bunch of hacks to have glibc 2.29 Y2038 supporting. However, my policy now is "upstream first" - so I would recommend adding any further glibc work on top of [2]. > and > start testing this out with debian-rebootstrap [1]? I've been using OE/Yocto for testing as it allows building glibc sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and mips - but not tested). I'm able to use runqemu to test the built glibc with kernel 4.19, 5.1 (for armv7). This qemu run system can be used to run-test glibc tests on ARM32 with test-wrapper='/opt/Y2038/glibc/src/scripts/cross-test-ssh.sh Last but not least - OE/Yocto is used to provide BSP for embedded systems, so I'm aligned with customers' needs. However, I did not yet tried debian-rebootstrap. I will look if this can be reused as well. > > Are there any glibc issues that prevent it from working correctly, I think that the glibc wrappers for most important syscalls are now converted. What is missing: - NTPL (threads) - stat - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have some basic tests [4], but this may be not enough. > aside from the exact ABI not being final yet? > > Arnd > > [1] https://wiki.debian.org/HelmutGrohne/rebootstrap Links: [1] - https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1 [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge [3] - https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-warrior-01-08-2019 [4] - https://github.com/lmajewski/y2038-tests Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpaiYV0yumbs.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
Hi Vineet, > On 2/19/20 12:30 AM, Andreas Schwab wrote: > > On Feb 19 2020, Vineet Gupta wrote: > > > >> On 2/18/20 5:03 PM, Alistair Francis wrote: > >>>>> +#define STAT_IS_KERNEL_STAT 1 > >>>> Isn't this irrelevant: seems to be only used for legacy > >>>> __NR_stat/__NR_stat64 syscalls based__xstat()/__xstat64(). > >>> Is it? It seems to be used in a few places, including: > >>> > >>> sysdeps/unix/sysv/linux/fxstatat.c > >>> sysdeps/unix/sysv/linux/xstatconv.c > >> AFAIK that is not part of the asm-generic syscall ABI which ARC, > >> RISCV et al use ! > > > > The latter is still included by everyone, though. > > Correct, although it only builds a "dummy" struct for #ifdef > STAT_IS_KERNEL_STAT i.e. for either values of this define - we might > as well move that dummy out and make the rest of code ifndef. > > Rest of code in that function __xstat_conv is not meant for > asm-generic syscall ABI anyways. Please keep in mind that there are some architectures (like 32 bit ARM), which are NOT using asm-generic API. Those archs also require support for 64 bit time. That is why Alistair put the [sg]etitimer conversion code into sysdeps/unix/sysv/linux/ directory. In that way all eligible archs could reuse the same conversion code. > > Thx, > -Vineet > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpPs4Mscr0_L.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Vineet,
> Hi Alistair, Arnd
>
> On 2/14/20 2:39 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > wrote:
> >> On Tue, 11 Feb 2020, Alistair Francis wrote:
> >>
> >>>>> diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> >>>>> b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h new file mode
> >>>>> 100644 index 00..0da3bdeb5d
> >>>>> --- /dev/null
> >>>>> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> >>>> I was hoping newer arches could simply use the asm-generic one ?
> >>>>
> >>> We need to specify that RV32 uses a 64-bit time_t. The generic
> >>> ones don't do that for 32-bit arches.
> >> Since it seems we'd like future 32-bit ports of glibc to use
> >> 64-bit time and offsets, we should make that as easy as possible.
> >>
> >> That is, you need an RISC-V-specific bits/timesize.h. But you
> >> shouldn't need an RISC-V-specific bits/typesizes.h - rather, make
> >> the linux/generic one do the right thing for __TIME_T_TYPE based
> >> on bits/timesize.h. And have some other header that 32-bit
> >> linux/generic ports can use to say whether they use the 64-bit
> >> offset/stat/statfs interface, that bits/typesizes.h can use
> >> together with its existing __LP64__ check, and make the
> >> definitions of __OFF_T_TYPE etc. check that as well, and then you
> >> shouldn't need an RISC-V-specific bits/typesizes.h - the
> >> RISC-V-specific headers should be strictly minimal. (No
> >> architecture-specific bits/time64.h headers should be needed in
> >> any case.)
> > Ok, I have updated this. I'll send the patch once my "Always use
> > 32-bit time_t for certain syscalls" series is in (the headers are
> > changed in that series).
>
> I guess you haven't pushed changes yet, which don't make full copy of
> typesizes.h ?
>
> Anyhow I have a version based on your prior next branch where I
> switched ARC to 64-bit time_t - things work fine in general but I see
> some additional failures with the testsuite.
>
> Consider io/test-stat2.c which calls stat() and stat64() and compares
> the results: it now fails for ctime mismatch
>
> | ...
> | st_atime: [72] 644245094405576070 vs [72] 644245094405576070 OK
> | st_mtime: [88] 197568495616000 vs [88] 197568495616000 OK
> | st_ctime: [104] 0 vs [104] 2306351876938924035 FAIL
>
>
> In kernel asm-generic stat64 has 32-bit ctime (secs)
>
> struct stat64 {
> ...
> int st_atime; <-- offset 72
> unsigned int st_atime_nsec;
> int st_mtime; <-- offset *80*
> unsigned int st_mtime_nsec;
> int st_ctime; <-- offset 92
> unsigned int st_ctime_nsec;
> ...
> };
>
> In glibc, we have 64-bit time_t based timestamps so the structure
> diverges with kernel counterpart from time fields onwards.
>
> __extension__ typedef __int64_t __time_t; <-- ARC switched
> to 64-bit time_t
>
> struct timespec
> {
> __time_t tv_sec; <-- 8
> long int tv_nsec; <-- 4
> int: 32; <-- 4
> };
>
> struct stat64
> {
> ...
> struct timespec st_atim; <-- offset 72
> struct timespec st_mtim; <-- offset *88*
> struct timespec st_ctim; <-- offset 104
> int __glibc_reserved[2];
> };
>
> However glibc stat64()wrapper calls
> sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c
>
> which for ARC is just doing a pass thru syscall because we do have
> __NR_fstatat64
> - hence the issues I see.
>
> It needs itemized copy
>
> __xstat64 (int vers, const char *name, struct stat64 *buf)
> {
> #ifdef __NR_fstatat64
> return INLINE_SYSCALL (fstatat64, 4, AT_FDCWD, name, buf,
> 0); #else
>
> int rc = INLINE_SYSCALL (statx, 5, AT_FDCWD, name,
> AT_NO_AUTOMOUNT, STATX_BASIC_STATS, );
> __cp_stat64_statx (buf, );
> #endif
>
> An the reason this all works on RISCV is that your kernel doesn't
> define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the
> statx call which does itemized copy and would work fine when copying
> from 32-bits time (in kernel) to 64-bits container in glibc. Is this
> is right understanding or am I missing something here.
>
> How do I build a latest RISCV
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph, Vineet, > On Tue, 18 Feb 2020, Vineet Gupta wrote: > > > An the reason this all works on RISCV is that your kernel doesn't > > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses > > the statx call which does itemized copy and would work fine when > > copying from 32-bits time (in kernel) to 64-bits container in > > glibc. Is this is right understanding or am I missing something > > here. > > That looks right - so you'll need a way (e.g. a new macro in > kernel_stat.h) to tell the stat implementations to use the statx path > even though the older stat64 syscalls exist. > Similar issue is on ARM32 (armv7). It also uses stat instead of statx (and also needs some conversion to 64 bit types). Potential conversion patch could be reused on ARM32 as well. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpl7GETSASKq.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
