Re: Debian Hurd clock precision
On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > While debugging a timing problem with FFmpeg on Hurd, I noticed that the > "clock" function has a far lower precision on Hurd than it does on > Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > > I also found this patch to libc which may be responsible: > hurd-i386/unsubmitted-clock_t_centiseconds.diff > > I'm not entirely sure why patching libc is appropriate to fix the > claimed issues. The patch has nothing to do with precision. The kernel simply doesn't have any high resolution timing system, whereas Linux does. -- Richard Braun
Re: Debian Hurd clock precision
On 28/07/17 09:05, Richard Braun wrote: > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the >> "clock" function has a far lower precision on Hurd than it does on >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? >> >> I also found this patch to libc which may be responsible: >> hurd-i386/unsubmitted-clock_t_centiseconds.diff >> >> I'm not entirely sure why patching libc is appropriate to fix the >> claimed issues. > > The patch has nothing to do with precision. The kernel simply doesn't > have any high resolution timing system, whereas Linux does. In that case, clock should be returning multiples of whatever precision is supported by the kernel so that CLOCKS_PER_SEC is still correct. James signature.asc Description: OpenPGP digital signature
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: > On 28/07/17 09:05, Richard Braun wrote: > > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the > >> "clock" function has a far lower precision on Hurd than it does on > >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > >> > >> I also found this patch to libc which may be responsible: > >> hurd-i386/unsubmitted-clock_t_centiseconds.diff > >> > >> I'm not entirely sure why patching libc is appropriate to fix the > >> claimed issues. > > > > The patch has nothing to do with precision. The kernel simply doesn't > > have any high resolution timing system, whereas Linux does. > > In that case, clock should be returning multiples of whatever precision > is supported by the kernel so that CLOCKS_PER_SEC is still correct. That macro is required by XSI to have this value, as described by POSIX [1]. -- Richard Braun [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 11:10:29AM +0200, Richard Braun wrote: > On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: > > On 28/07/17 09:05, Richard Braun wrote: > > > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > > >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the > > >> "clock" function has a far lower precision on Hurd than it does on > > >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > > >> > > >> I also found this patch to libc which may be responsible: > > >> hurd-i386/unsubmitted-clock_t_centiseconds.diff > > >> > > >> I'm not entirely sure why patching libc is appropriate to fix the > > >> claimed issues. > > > > > > The patch has nothing to do with precision. The kernel simply doesn't > > > have any high resolution timing system, whereas Linux does. > > > > In that case, clock should be returning multiples of whatever precision > > is supported by the kernel so that CLOCKS_PER_SEC is still correct. > > That macro is required by XSI to have this value, as described by POSIX [1]. I replied too quickly. I don't have all the details in mind but you may be right. Please use the bug-h...@gnu.org mailing list to report this issue upstream. -- Richard Braun
Re: Debian Hurd clock precision
On 28/07/17 10:13, Richard Braun wrote: > On Fri, Jul 28, 2017 at 11:10:29AM +0200, Richard Braun wrote: >> On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: >>> On 28/07/17 09:05, Richard Braun wrote: On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > While debugging a timing problem with FFmpeg on Hurd, I noticed that the > "clock" function has a far lower precision on Hurd than it does on > Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > > I also found this patch to libc which may be responsible: > hurd-i386/unsubmitted-clock_t_centiseconds.diff > > I'm not entirely sure why patching libc is appropriate to fix the > claimed issues. The patch has nothing to do with precision. The kernel simply doesn't have any high resolution timing system, whereas Linux does. >>> >>> In that case, clock should be returning multiples of whatever precision >>> is supported by the kernel so that CLOCKS_PER_SEC is still correct. >> >> That macro is required by XSI to have this value, as described by POSIX [1]. > > I replied too quickly. I don't have all the details in mind but you may > be right. Please use the bug-h...@gnu.org mailing list to report this > issue upstream. I have a feeling it's not an upstream issue. The patch I mentioned above is only applied in Debian's glibc package. Thanks, James signature.asc Description: OpenPGP digital signature
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 10:17:47AM +0100, James Cowgill wrote: > I have a feeling it's not an upstream issue. The patch I mentioned above > is only applied in Debian's glibc package. Which is the only one really in use, and maintained by the same people, but for some reason, you have a much better chance on bug-hurd. -- Richard Braun
Re: Debian Hurd clock precision
James Cowgill, on ven. 28 juil. 2017 09:58:54 +0100, wrote: > On 28/07/17 09:05, Richard Braun wrote: > > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the > >> "clock" function has a far lower precision on Hurd than it does on > >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > >> > >> I also found this patch to libc which may be responsible: > >> hurd-i386/unsubmitted-clock_t_centiseconds.diff > >> > >> I'm not entirely sure why patching libc is appropriate to fix the > >> claimed issues. > > > > The patch has nothing to do with precision. The kernel simply doesn't > > have any high resolution timing system, whereas Linux does. > > In that case, clock should be returning multiples of whatever precision > is supported by the kernel so that CLOCKS_PER_SEC is still correct. The problem is that applications use it to determine in what units are the values in /proc/ , and others assume 100 there. So we're stuck with 100 in all of this. Samuel
dropbear: tfbfs on x32
I just saw that there is only an very old version of dropbear in the
repository and tried to build current 2017.75. This fails in the file
tomcrypt_macros.h with an error similar to
https://wiki.debian.org/X32Port#amd64_assembly.
Attached is a full build log.
kind regards
txt.file
dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package dropbear
dpkg-buildpackage: info: source version 2017.75-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Guilhem Moulin
dpkg-source --before-build dropbear-2017.75
dpkg-buildpackage: info: host architecture x32
fakeroot debian/rules clean
dh clean --with=autoreconf
dh_testdir
dh_auto_clean
dh_autoreconf_clean
dh_clean
dpkg-source -b dropbear-2017.75
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building dropbear using existing ./dropbear_2017.75.orig.tar.bz2
dpkg-source: info: building dropbear in dropbear_2017.75-1.debian.tar.xz
dpkg-source: info: building dropbear in dropbear_2017.75-1.dsc
debian/rules build
dh build --with=autoreconf
dh_testdir
dh_update_autotools_config
dh_autoreconf
debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/txt/workspace/dropbear-2017.75'
dh_auto_configure -- --enable-bundled-libtom \
CC='gcc' CFLAGS='-g -O2 -fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DSFTPSERVER_PATH="\"/usr/lib/sftp-server\""' \
./configure --build=x86_64-linux-gnux32 --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnux32 --libexecdir=\${prefix}/lib/x86_64-linux-gnux32 --disable-maintainer-mode --disable-dependency-tracking --enable-bundled-libtom CC=gcc "CFLAGS=-g -O2 -fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DSFTPSERVER_PATH=\"\\\"/usr/lib/sftp-server\\\"\""
configure: WARNING: unrecognized options: --disable-silent-rules, --disable-maintainer-mode, --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether make sets $(MAKE)... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking build system type... x86_64-pc-linux-gnux32
checking host system type... x86_64-pc-linux-gnux32
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for install... install
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __UCLIBC__ is declared... no
checking for crypt... no
checking for crypt in -lcrypt... yes
checking for deflate in -lz... yes
configure: Enabling zlib
configure: Disabling PAM
configure: Using openpty if available
checking for library containing openpty... -lutil
configure: Enabling syslog
checking shadow.h usability... yes
checking shadow.h presence... yes
checking for shadow.h... yes
configure: Using shadow passwords if available
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/tcp.h usability... yes
checking netinet/tcp.h presence... yes
checking for netinet/tcp.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for unistd.h... (cached) yes
checking crypt.h usability... yes
checking crypt.h
