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 (&m); >> >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 (&m); >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
Why does install-headers depend on crt*.o? That appears to be the regression to fix. 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: [PATCH] hurd: fix for glibc install-headers target
Samuel Thibault 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: > 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: 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: >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: >> 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: > 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: 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
