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: [PATCH] Force 64-bit time based syscalls for TIMESIZE==64 on 32-bit arches
* Vineet Gupta: > +/* Override syscalls for asm-generic ABIs with 64-bit time. */ > +#if __WORDSIZE == 32 && __TIMESIZE == 64 > + > +# undef __NR_futex > +# define __NR_futex __NR_futex_time64 > + > +# undef __NR_rt_sigtimedwait > +# define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64 I'm not totally unsympathetic to this in principle, but I think if we start messing more with the system call numbers in this way, we should move away from the __NR_ prefixes and use our own constant names. Otherwise, the results could be very confusing, especially if there are exceptions to this exception and we need the original system call number after all. Thanks, Florian ___ 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
http:/
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: [PATCH v3] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64
On Mon, 24 Feb 2020, Vineet Gupta wrote: > Oh wait. Can we avoid this churn by simply undef __NR_fstat64 and > __NR_fstatat64 > from ARC sysdep.h ? And it will then automatically fallback to statx code ! If all files needing this information include sysdep.h, that might well work. -- 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: [PATCH v3] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64
On 2/25/20 8:10 AM, Joseph Myers wrote: > On Mon, 24 Feb 2020, Vineet Gupta wrote: > >> Oh wait. Can we avoid this churn by simply undef __NR_fstat64 and >> __NR_fstatat64 >> from ARC sysdep.h ? And it will then automatically fallback to statx code ! > > If all files needing this information include sysdep.h, that might well > work. I agree that this is a valid concern. If we really want to make it water tight we could have the build system enforce this with -include or some such ? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
