On Tue, 17 Mar 2020 08:47:24 +0100
Lukasz Majewski <lukma@denx.de> wrote:

> Dear community,
> 
> I'm trying to replace all the occurences of __clock_gettime with
> __clock_gettime64 to avoid time bugs on archs with __WORDSIZE == 32 &&
> __TIMESIZE != 64 (for now I've omitted the conversion of ntpl,
> pthreads,sunrpc)
> 
> I've modified: sysdeps/generic/memusage.h (the GETTIME preprocessor
> macro).
> 
> Unfortunately, several glibc builds fail:
> arm-glibc-linux-gnueabi-gcc   -shared -static-libgcc -Wl,-O1
> -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.3
> -B/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/csu/
>   -Wl,-soname=libmemusage.so -Wl,-z,combreloc -Wl,-z,relro
> -Wl,--hash-style =both
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/math
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf
> -L/home/lukma/work/
> glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nss
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nis
> -L/home/lukma/work/glibc/glibc-many-build
> /build/glibcs/arm-linux-gnueabi/glibc/rt
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/resolv
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/mathvec
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-
> linux-gnueabi/glibc/support
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/crypt
> -L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nptl
> -Wl,-rpath-link=/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-lin
> ux-gnueabi/glibc:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/math:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn:/home/lukm
> a/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nss:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nis:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/rt:/home/lukma/work/glibc/glibc-many-build/b
> uild/glibcs/arm-linux-gnueabi/glibc/resolv:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/mathvec:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/support:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-lin
> ux-gnueabi/glibc/crypt:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nptl
> -o
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage.so
> -T /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-
> gnueabi/glibc/shlib.lds
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/csu/abi-note.o
> -Wl,--whole-archive
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a
> -Wl,--no-whole-archive /home/lukma/
> work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn/libdl.so.2
>   -Wl,--start-group
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc_nons
> hared.a -Wl,--as-needed
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf/ld.so
> -Wl,--no-as-needed -Wl,--end-group
> /work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
> ): in function `update_data':
> /work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:181:
> undefined reference to `__clock_gettime64'
> /work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
> ): in function `me':
> /work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:271:
> undefined reference to `__clock_gettime64'
> /work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
> /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
> ): in function `dest':
> /work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:822:
> undefined reference to `__clock_gettime64' collect2: error: ld
> returned 1 exit status
> 
> 
> 
> This is what I see from the local build directory:
> nm
> ./work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
> | grep clock_gettime
> 
> 0009a8e0 T __clock_gettime
> 0009a8e0 t __clock_gettime_2
> 0009a774 t __clock_gettime64
> 0009a8e0 T clock_gettime@@GLIBC_2.17
> 0009a8e0 T clock_gettime@GLIBC_2.4
> 0009a8e0 t __GI___clock_gettime
> 0009a774 t __GI___clock_gettime64
> 
> Apparently the __clock_gettime64 is a local symbol in the libc.so.
> 
> 
> However, I've checked how it looks on the installed glibc:
> root@y2038arm:/opt# nm /opt/lib/libc.so.6 | grep clock_gettime
> 
> 000702bc t __GI___clock_gettime
> 00070264 t __GI___clock_gettime64
> 000702bc T __clock_gettime
> 00070264 T __clock_gettime64
> 000702bc t __clock_gettime_2
> 000702bc T clock_gettime@@GLIBC_2.17
> 000702bc T clock_gettime@GLIBC_2.4
> 
> In the installed glibc the __clock_gettime64 is an external symbol.
> 
> 
> Why the symbol (__clock_gettime64) is local when I try to link
> malloc/libmemusage.so and then it becomes global when glibc is
> installed?
> 
> In other parts of the glibc - for example
> sysdeps/unix/sysv/linux/clock.c I can use __clock_gettime64 without
> any issues. 
> 
> Is such behavior related to strong_allias() declaration (as for
> example in __clock_settime for which we do have similar situation)?
> 
> 

Does anybody have any input on the described above problem?

Thanks in advance.

> 
> 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:
> lukma@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: lukma@denx.de