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)
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. 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.) -- Joseph S. Myers jos...@codesourcery.com ___ 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)
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? _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. 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). 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. > 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. -- Joseph S. Myers jos...@codesourcery.com ___ 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
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
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, Feb 24, 2020 at 10:01 AM Lukasz Majewski wrote: > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > > wrote: > > 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. Ok, thanks for taking a look, I won't debug this further then, unless you need help reproducing the issues. Arnd ___ 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, 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. 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. It's true that the redirection from lib_hidden_proto doesn't work when there is another redirection for the same symbol in effect, 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). -- Joseph S. Myers jos...@codesourcery.com ___ 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)
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 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. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ 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)
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. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ 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)
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. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ 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)
On 20-02-20, 15:44, Arnd Bergmann wrote: > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote: > > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > 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. What you said is correct Arnd. It is in very early stage of planning right now, no guarantees on when will we start working on it as of now. -- viresh ___ 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 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): +-+ | 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 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? Arnd ___ 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 Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann wrote: > > 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. We have started to do that for RISC-V 32-bit. I have fixed up some things in Busybox and OpenSSL to improve 64-bit time_t support on 32-bit archs. In meta-riscv (and OpenEmbedded layer) we are tracking issues: https://github.com/riscv/meta-riscv/issues/202 Right now it's all compile focused though, not so much run time testing. Alistair > > > > 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? 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. 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. > > > - 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. There is also some work > in Linaro to ensure that LTP tests the low-level syscall interfaces > in both the time32 and time64 variants. > > Arnd ___ 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 09:31:32AM +0100, Arnd Bergmann wrote: > > > 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 and > start testing this out with debian-rebootstrap [1]? This is exacty what rebootstrap is for. You should be able to experiment with different ABIs without committing to a particular ABI. You can fiddle with such aspects and then cross build a pile of around 120 Debian packages. That should uncover the most significant problems. You don't even have to change the GNU triplet. You can just create an incompatible throw-away port with an existing architecture name as rebootstrap refuses to reuse any existing binary packages for the host architecture. If you want to pursue that route, get in touch with debian-cr...@lists.debian.org or #debian-bootstrap on irc.oftc.net. The usual route is forking the rebootstrap.git repository. You just hack up your toolchain modifications an retry the bootstrap from scratch until you are satisfied. Be prepared to put up with half a day or a day of CPU time for a single run. Don't hesitate to ask for help if you have undecipherable build failures. Balint Reczey has done something quite similar to what you're up to: He attempted creating ports that are instrumented with sanitizers. Since I saw arc in the subject, I also threw arc at rebootstrap. Turns out that glibc 2.30 does not yet cover arc and using unpackaged versions of glibc is non-trivial for rebootstrap, so I cannot do much about that. Once arc support is in a released version of glibc, I'd be happy to be pinged about it. Helmut ___ 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 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 __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 Arnd ___ 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)
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. > - 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 ___ 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: 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 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. > > 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? 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. 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. > - 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. There is also some work in Linaro to ensure that LTP tests the low-level syscall interfaces in both the time32 and time64 variants. Arnd ___ 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: 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 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 and start testing this out with debian-rebootstrap [1]? Are there any glibc issues that prevent it from working correctly, aside from the exact ABI not being final yet? Arnd [1] https://wiki.debian.org/HelmutGrohne/rebootstrap ___ 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 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).
>
> 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
pgpITOdXYrQGk.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)
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
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 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. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
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 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 32-bit kernel + userland - do you have a buildroot
branch somewhere that I can build / test with qemu ?
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
