Re: [hurd, commited] socket: Fix tst-cmsghdr-skeleton.c use of cmsg_len
On Mai 01 2023, Samuel Thibault wrote: > Andreas Schwab, le lun. 01 mai 2023 15:38:45 +0200, a ecrit: >> On Mai 01 2023, Samuel Thibault wrote: >> >> > cmsg_len is supposed to be socklen_t according to standards, but it was >> > made >> > size_t on Linux, see BZ 16919. For ports that have it socklen_t, SIZE_MAX >> > is >> > too large. We can however explicitly cast it to the type of cmsg_len so it >> > will fit according to that type. >> > --- >> > socket/tst-cmsghdr-skeleton.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/socket/tst-cmsghdr-skeleton.c b/socket/tst-cmsghdr-skeleton.c >> > index 296a0a8581..9516139f87 100644 >> > --- a/socket/tst-cmsghdr-skeleton.c >> > +++ b/socket/tst-cmsghdr-skeleton.c >> > @@ -49,7 +49,7 @@ RUN_TEST_FUNCNAME (CMSG_NXTHDR_IMPL) (void) >> >/* The first header length is so big, using it would cause an overflow. >> > */ >> >cmsg = CMSG_FIRSTHDR (); >> >TEST_VERIFY_EXIT ((char *) cmsg == cmsgbuf); >> > - cmsg->cmsg_len = SIZE_MAX; >> > + cmsg->cmsg_len = (__typeof (cmsg->cmsg_len)) SIZE_MAX; >> >> What does that fix? > > 64bit hurd, where cmsg_len is socklen_t as the standards require (thus > 32bit). And what does it fix? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [hurd, commited] socket: Fix tst-cmsghdr-skeleton.c use of cmsg_len
On Mai 01 2023, Samuel Thibault wrote: > cmsg_len is supposed to be socklen_t according to standards, but it was made > size_t on Linux, see BZ 16919. For ports that have it socklen_t, SIZE_MAX is > too large. We can however explicitly cast it to the type of cmsg_len so it > will fit according to that type. > --- > socket/tst-cmsghdr-skeleton.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/socket/tst-cmsghdr-skeleton.c b/socket/tst-cmsghdr-skeleton.c > index 296a0a8581..9516139f87 100644 > --- a/socket/tst-cmsghdr-skeleton.c > +++ b/socket/tst-cmsghdr-skeleton.c > @@ -49,7 +49,7 @@ RUN_TEST_FUNCNAME (CMSG_NXTHDR_IMPL) (void) >/* The first header length is so big, using it would cause an overflow. */ >cmsg = CMSG_FIRSTHDR (); >TEST_VERIFY_EXIT ((char *) cmsg == cmsgbuf); > - cmsg->cmsg_len = SIZE_MAX; > + cmsg->cmsg_len = (__typeof (cmsg->cmsg_len)) SIZE_MAX; What does that fix? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: x86_64-gnu port -- help needed
On Mär 09 2023, Sergey Bugaev wrote:
> x86_64-gnu-gcc -nostdlib -nostartfiles -r -o elf/librtld.map.o
> elf/librtld.mapT.o '-Wl,-(' elf/dl-allobjs.os libc_pic.a
> mach/libmachuser_pic.a hurd/libhurduser_pic.a -lgcc '-Wl,-)'
> -Wl,-Map,elf/librtld.mapT
> x86_64-gnu/bin/ld: libc_pic.a(_exit.os): in function `__GI__exit':
> posix/../sysdeps/mach/hurd/_exit.c:50: multiple definition of `__GI__exit';
> elf/dl-allobjs.os:elf/../sysdeps/mach/hurd/dl-sysdep.c:728: first defined
> here
The only symbol provided by _exit.os that is not defined by
../sysdeps/mach/hurd/dl-sysdep.c is _Exit. Does anything call this
function?
> x86_64-gnu/bin/ld: libc_pic.a(strtoul.os): in function
> `__GI___strtoul_internal':
> stdlib/../sysdeps/wordsize-64/strtoul.c:108: multiple definition of
> `__GI___strtoul_internal';
> elf/dl-allobjs.os:elf/../sysdeps/mach/hurd/dl-sysdep.c:713: first defined
> here
Similarily, something is pulling in strtoul.os because it references a
symbol from there not defined by ../sysdeps/mach/hurd/dl-sysdep.c.
elf/librtld.mapT should tell you where the references come from.
> 1. What is this about, what's it even trying to do? If this is linking the
> dynamic linker (ld.so / rtld — these are the same thing, right?), then why
> does it need the dl-sysdep version if the real version is available?
The comments in ../sysdeps/mach/hurd/dl-sysdep.c indicate that the
dynamic linker wants to use some stripped down implementation of these
functions.
> 3. How come this works on i686-gnu, the duplicated symbols are clearly
> present there too!
Pure luck, perhaps.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [hurd,commited] hurd: Increase SOMAXCONN to 4096
On Sep 27 2022, Samuel Thibault wrote: > Notably fakeroot-tcp may introduce a lot of parallel connections. > --- > sysdeps/mach/hurd/bits/socket.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sysdeps/mach/hurd/bits/socket.h b/sysdeps/mach/hurd/bits/socket.h > index 70fce4fb27..4ece37f1dd 100644 > --- a/sysdeps/mach/hurd/bits/socket.h > +++ b/sysdeps/mach/hurd/bits/socket.h > @@ -147,7 +147,7 @@ enum __socket_type > #define AF_MAX PF_MAX > > /* Maximum queue length specifiable by listen. */ > -#define SOMAXCONN128 /* 5 on the origional 4.4 BSD. */ > +#define SOMAXCONN4096/* 5 on the origional 4.4 BSD. */ Perhaps fix the comment as well. -- 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."
Re: [PATCH] hurd: '_hurd_raise_signal' checks signal number is valid
https://sourceware.org/git/?p=glibc.git;a=commit;h=785ec62dbd Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [hurd,commited 6/6] htl: Enable more cancellation tests
../Rules:219: target '/suse/schwab/src/libc/test/nptl/tst-cancelx9' given more than once in the same rule 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."
Re: [hurd,commited] htl: Enable more tests
On Jun 07 2020, Samuel Thibault wrote: > * htl/Makefile: Remove rules adding libpthread.so and libpthread.a to link > lines. > * nptl/Makefile: Move rules adding libpthread.so and libpthread.a to > link lines to... > * sysdeps/pthread/Makefile: ... here. That breaks powerpc: /usr/lib64/gcc/powerpc64-suse-linux/10/../../../../powerpc64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/glibc-2.31.9000.532.g314a431d37/cc-base/support/libsupport_nonshared.a(xpthread_create.oS): in function `xpthread_create': /home/abuild/rpmbuild/BUILD/glibc-2.31.9000.532.g314a431d37/support/xpthread_create.c:26: undefined reference to `pthread_create' /usr/lib64/gcc/powerpc64-suse-linux/10/../../../../powerpc64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/glibc-2.31.9000.532.g314a431d37/cc-base/support/libsupport_nonshared.a(xpthread_join.oS): in function `xpthread_join': /home/abuild/rpmbuild/BUILD/glibc-2.31.9000.532.g314a431d37/support/xpthread_join.c:25: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status make[2]: *** [../Rules:223: /home/abuild/rpmbuild/BUILD/glibc-2.31.9000.532.g314a431d37/cc-base/nptl/test-get_hwcap] Error 1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [hurd,commited] hurd: Add THREAD_GET/SETMEM/_NC
On Feb 15 2020, Samuel Thibault wrote:
> diff --git a/sysdeps/mach/hurd/i386/tls.h b/sysdeps/mach/hurd/i386/tls.h
> index c0341ce2c9..7ec8c81a76 100644
> --- a/sysdeps/mach/hurd/i386/tls.h
> +++ b/sysdeps/mach/hurd/i386/tls.h
> @@ -163,6 +163,114 @@ out:
> : "i" (offsetof (tcbhead_t, tcb))); \
> __tcb;})
>
> +/* Read member of the thread descriptor directly. */
> +# define THREAD_GETMEM(descr, member) \
> + ({ __typeof (descr->member) __value;
> \
> + if (sizeof (__value) == 1)
> \
> + asm volatile ("movb %%gs:%P2,%b0" \
> + : "=q" (__value) \
> + : "0" (0), "i" (offsetof (tcbhead_t, member))); \
> + else if (sizeof (__value) == 4) \
> + asm volatile ("movl %%gs:%P1,%0"
> \
> + : "=r" (__value) \
> + : "i" (offsetof (tcbhead_t, member))); \
> + else \
> + { \
> + if (sizeof (__value) != 8) \
> +/* There should not be any value with a size other than 1, \
> + 4 or 8. */ \
> +abort (); \
_Static_assert?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [hurd,commited] hurd sendmsg: Fix warning on calling CMSG_*HDR
On Dez 29 2019, Florian Weimer wrote: > * Andreas Schwab: > >> On Dez 29 2019, Samuel Thibault wrote: >> >>> diff --git a/sysdeps/mach/hurd/sendmsg.c b/sysdeps/mach/hurd/sendmsg.c >>> index 0c19b3223c..3d7317cec4 100644 >>> --- a/sysdeps/mach/hurd/sendmsg.c >>> +++ b/sysdeps/mach/hurd/sendmsg.c >>> @@ -108,7 +108,7 @@ __libc_sendmsg (int fd, const struct msghdr >>> *message, int flags) >>> >>>/* Allocate enough room for ports. */ >>>cmsg = CMSG_FIRSTHDR (message); >>> - for (; cmsg; cmsg = CMSG_NXTHDR (message, cmsg)) >>> + for (; cmsg; cmsg = CMSG_NXTHDR ((struct msghdr *) message, cmsg)) >> >> Why is the first argument of __cmsg_nxthdr not const? > > Some programmers expect that CMSG_NXTHDR can be used to construct > ancillary data. See bug 13500. How is that related to the first argument? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [hurd,commited] hurd sendmsg: Fix warning on calling CMSG_*HDR
On Dez 29 2019, Samuel Thibault wrote: > Andreas Schwab, le dim. 29 déc. 2019 18:12:02 +0100, a ecrit: >> > - for (; cmsg; cmsg = CMSG_NXTHDR (message, cmsg)) >> > + for (; cmsg; cmsg = CMSG_NXTHDR ((struct msghdr *) message, cmsg)) >> >> Why is the first argument of __cmsg_nxthdr not const? > > I don't know, it is so on other systems as well. > > I guess an issue is that if it was const, CMSG_NXTHDR would only > be allowed to return a const, The return value is not based on the first argument. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [hurd,commited] hurd sendmsg: Fix warning on calling CMSG_*HDR
On Dez 29 2019, Samuel Thibault wrote: > diff --git a/sysdeps/mach/hurd/sendmsg.c b/sysdeps/mach/hurd/sendmsg.c > index 0c19b3223c..3d7317cec4 100644 > --- a/sysdeps/mach/hurd/sendmsg.c > +++ b/sysdeps/mach/hurd/sendmsg.c > @@ -108,7 +108,7 @@ __libc_sendmsg (int fd, const struct msghdr *message, int > flags) > >/* Allocate enough room for ports. */ >cmsg = CMSG_FIRSTHDR (message); > - for (; cmsg; cmsg = CMSG_NXTHDR (message, cmsg)) > + for (; cmsg; cmsg = CMSG_NXTHDR ((struct msghdr *) message, cmsg)) Why is the first argument of __cmsg_nxthdr not const? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] hurd: fix for glibc install-headers target
Samuel Thibault samuel.thiba...@gnu.org writes: and this goes on at infinitum. Make -d shows that it is trying to build /tmp/glibc-2.19/build-tree/hurd-i386-libc/mach/mach-shortcuts.h and adding a $(warning) shows that the generated mach-shortcuts.h rule is for /tmp/glibc-2.19/build-tree/hurd-i386-libc/csu/mach-shortcuts.h (in csu/ instead of mach/). AIUI, the patch below would be needed to fix the objpfx so that the proper rule is generated, isn't it? The first thing mach/Makefile does is subdir := mach. Why is that not sufficient? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: New option for ln, firmlinks!
Alfred M. Szmidt [EMAIL PROTECTED] writes: Howdy, The following hack implements the --firm/-m option for ln so that it will create firm links. Now, most GNU/Linux people won't be familiar with the concept, and I'm not really sure how to explain it either. The best example I can think of that explains the difference between symlinks and firmlinks is the following: hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink hurd:/home/ams/coreutils/coreutils/src# cd symlink hurd:/home/ams/coreutils/coreutils/src/symlink# ls .. foo hurd.obj lost+found oskit.obj sub-hurd hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink hurd:/home/ams/coreutils/coreutils/src/firmlink# ls .. CVS Makefile Makefile.am [..snip...] This looks similar to bind mounts in Linux. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: New option for ln, firmlinks!
Alfred M. Szmidt [EMAIL PROTECTED] writes: hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink hurd:/home/ams/coreutils/coreutils/src# cd symlink hurd:/home/ams/coreutils/coreutils/src/symlink# ls .. foo hurd.obj lost+found oskit.obj sub-hurd hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink hurd:/home/ams/coreutils/coreutils/src/firmlink# ls .. CVS Makefile Makefile.am [..snip...] This looks similar to bind mounts in Linux. Are those the same thing as union file-systems I don't know much about union file-systems, but AFAIK they are different from bind mounts. A bind mount is created by mount -o bind /foo /bar and causes the tree under /foo to be overlayed over /bar, with the former contents of /bar being hidden. It's like a regular mount, except that the source is not (a filesystem on) a block device, but a directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: New option for ln, firmlinks!
Alfred M. Szmidt [EMAIL PROTECTED] writes: I don't know much about union file-systems, but AFAIK they are different from bind mounts. A bind mount is created by mount -o bind /foo /bar and causes the tree under /foo to be overlayed over /bar, with the former contents of /bar being hidden. It's like a regular mount, except that the source is not (a filesystem on) a block device, but a directory. It does sound a bit similar to firmlinks. But firmlinks work on any kind of type of file (directories, symlinks, ...). I don't know if this bind file-system can be used across chroots, but firmlinks can. You can also bind-mount a regular file (and probably other types, I didn't try yet). The only difference to firmlinks is, at it seems, that the destination must already exist and it must be of the same type as the source. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: New option for ln, firmlinks!
Alfred M. Szmidt [EMAIL PROTECTED] writes: You can also bind-mount a regular file (and probably other types, I didn't try yet). The only difference to firmlinks is, at it seems, that the destination must already exist and it must be of the same type as the source. Not entirerly true, the source and destination aren't the same in any way, The last sentence above was attributed to bind mounts, not to firmlinks. Was it possible to jump out of a chroot with bind's? Not sure what you mean. A bind-mountpoint behaves like any other mountpoint. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: New option for ln, firmlinks!
Alfred M. Szmidt [EMAIL PROTECTED] writes: Well, can you do the something along the following with bind-mountpoints (using settrans to be clear): $ settrans -ac /new-root/etc /hurd/firmlink /etc $ chroot /new-root $ cat /etc/passwd And get the content of REAL-ROOT/etc/passwd for example? Yes. The binding is evaluated at mount-time. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: snprintf
James Morrison [EMAIL PROTECTED] writes: | Hello, | I've noticed that on GNU/Hurd snprintf doesn't work if | the expanded template exceeds the size given. | | eg | char limited[5]; | snprintf(limited,5,12345); | | On GNU/Linux with libio snprintf sets limited to 1234 and returns | 5. This is correct: 7.19.6.5 The snprintf function [#2] The snprintf function is equivalent to fprintf, except that the output is written into an array (specified by argument s) rather than to a stream. If n is zero, nothing is written, and s may be a null pointer. Otherwise, output characters beyond the n-1st are discarded rather than being written to the array, and a null character is written at the end of the characters actually written into the array. If copying takes place between objects that overlap, the behavior is undefined. Returns [#3] The snprintf function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character, or a neg ative value if an encoding error occurred. Thus, the null-terminated output has been completely written if and only if the returned value is nonnegative and less than n. Andreas. -- Andreas Schwab And now for something [EMAIL PROTECTED] completely different. SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
