daily CVS update output
Updating src tree: P src/distrib/notes/alpha/contents P src/distrib/notes/common/contents P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/man/mi P src/distrib/sets/lists/tests/mi P src/doc/CHANGES P src/external/gpl3/gcc/lib/libsupc++/Makefile.common P src/external/gpl3/gdb/lib/libctf/Makefile P src/external/mit/xorg/bin/xinit/Makefile P src/include/link_elf.h P src/lib/libc/time/strptime.c P src/libexec/ld.elf_so/load.c P src/libexec/ld.elf_so/rtld.c P src/libexec/ld.elf_so/rtld.h P src/share/man/man4/rum.4 P src/share/man/man4/man4.amiga/Makefile P src/share/man/man4/man4.sparc/intro.4 P src/sys/arch/arm/arm/armv6_start.S P src/sys/arch/arm/arm/undefined.c P src/sys/dev/ic/rtl8169.c P src/sys/dev/ic/rtl81x9reg.h P src/sys/dev/ic/rtl81x9var.h P src/sys/uvm/uvm_amap.c P src/sys/uvm/uvm_io.c P src/tests/libexec/ld.elf_so/Makefile U src/tests/libexec/ld.elf_so/t_rtld_r_debug.c P src/usr.bin/make/arch.c P src/usr.bin/make/compat.c P src/usr.bin/make/dir.c P src/usr.bin/make/dir.h P src/usr.bin/make/job.c P src/usr.bin/make/job.h P src/usr.bin/make/make.h P src/usr.bin/make/meta.c P src/usr.bin/make/nonints.h P src/usr.bin/make/parse.c P src/usr.bin/make/test-variants.sh P src/usr.bin/make/var.c P src/usr.bin/make/unit-tests/Makefile P src/usr.bin/make/unit-tests/varname-dot-parsedir.exp P src/usr.bin/make/unit-tests/varname-dot-parsedir.mk P src/usr.bin/make/unit-tests/varname-dot-parsefile.exp P src/usr.bin/make/unit-tests/varname-dot-parsefile.mk P src/usr.sbin/sysinst/arch/alpha/md.h P src/usr.sbin/sysinst/arch/alpha/msg.md.de P src/usr.sbin/sysinst/arch/alpha/msg.md.en P src/usr.sbin/sysinst/arch/alpha/msg.md.es P src/usr.sbin/sysinst/arch/alpha/msg.md.fr P src/usr.sbin/sysinst/arch/alpha/msg.md.pl Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 45094040 Sep 22 03:04 ls-lRA.gz
Re: libpthread problem when using custom stack
On Tue, Sep 22, 2020 at 12:34:12AM +0200, Thomas Klausner wrote: > According to the NetBSD man page for pthread_attr_setguardsize(), the > effect of this function is ignored when pthread_attr_setstack() is > used. This does not seem to be the case here. That's not exactly what happens. libpthread computes the initial stack pointer based on the stack base, stack size and guard size. It doesn't allocate the stack itself nor does it change any mapping in it. I'm not sure if it is supposed to assume guardsize == 0 for the pointer calculation though. Joerg
libpthread problem when using custom stack
Hi!
devel/p5-Coro is a perl module providing threading support.
The current version 6.57 had lots of segfaults on NetBSD. I
investigated with help of the author Marc Lehmann.
We found that setting up the stack (i.e. the mmap()s) worked fine, but
then actually using the stack lead to random segfaults.
The code is quite straightforward (unifdef'ed for NetBSD), see below.
When used as shown below, the random segfaults happen. When the
(commented out) pthread_attr_setguardsize() is enabled, the segfaults
stop.
According to the NetBSD man page for pthread_attr_setguardsize(), the
effect of this function is ignored when pthread_attr_setstack() is
used. This does not seem to be the case here.
--- begin quote from pthread_attr_getguardsize(3) ---
If pthread_attr_setstack(3) or pthread_attr_setstackaddr(3) is used to
set the stack address attribute in attr, the guard size attribute is
ignored and no guard area will be allocated; it is the responsibility
of the application to handle the overflow conditions.
--- end quote ---
Last year's GSoC porting wine had a similar issue, see
https://blog.netbsd.org/tnf/entry/porting_wine_to_amd64_on :
--- begin quote from blog entry ---
Eventually, I found that pthread_attr_setstack(3) was setting the
guard size to 65536 bytes even though the man page said otherwise. And
Wine relied on it not being set. This resulted in out-of-bound access
which caused the unhandled page fault. After setting the guard size to
0 using pthread_attr_setguardsize(3), Wine started behaving fine.
--- end quote ---
I think there is a bug in libpthread. Is this enough for a bug report
or what more information is needed? Or perhaps someone already knows
how to fix this?
Cheers,
Thomas
>From Coro-6.57/Coro/libcoro/coro.c:
void
coro_create (coro_context *ctx, coro_func coro, void *arg, void *sptr, size_t
ssize)
{
static coro_context nctx;
static int once;
if (!once)
{
once = 1;
pthread_cond_init (, 0);
}
pthread_cond_init (>cv, 0);
if (coro)
{
pthread_attr_t attr;
struct coro_init_args args;
pthread_t id;
args.func = coro;
args.arg = arg;
args.self = ctx;
args.main =
pthread_attr_init ();
// pthread_attr_setguardsize (, 0);
pthread_attr_setstack (, sptr, (size_t)ssize);
pthread_attr_setscope (, PTHREAD_SCOPE_PROCESS);
pthread_create (, , coro_init, );
coro_transfer (args.main, args.self);
}
}
re: Failure to build Current amd64
> > > In file included from > > > usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26: > > > /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error: > > > bits/largefile-config.h: No such file or directory > > >29 | #include > > > | ^ > > > > my fault, but this should be fixed now. > > I've updated from CVS the last couple of days, but I'm still getting this > same error. please try again now. there was a second problem i missed. .mrg.
re: current fails to build on amd64
Nikita Gillmann writes: > This is with a recent checkout after gcc9 import. If no one can > reproduce this, what can I do? OK, i see the problem -- should be fixed with external/gpl3/gcc/lib/libsupc++/Makefile.common rev 1.19 .mrg.
Re: current fails to build on amd64
$ uname -a
NetBSD ymir 9.99.73 NetBSD 9.99.73 (GENERIC) #7: Sat Sep 19 10:58:21
BST 2020
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
amd64
$ gcc --version
gcc (nb1 20200907) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It builds for me. I did remove the obj directory before the first
build expecting to bring gcc 9.3; I also - by old custom - run 'make
cleandir' in src and xsrc, whenever I remove the obj folder.
I've got another hour or so doing 'pkg_rolling-replace', then I am
going to build -current.
On Mon, 21 Sep 2020 at 18:21, Nikita Gillmann wrote:
>
> This is with a recent checkout after gcc9 import. If no one can
> reproduce this, what can I do?
>
> #create libstdc++-v3/cow-fs_dir.d
> CC=/usr/src/../tools/bin/x86_64--netbsd-c++
> /usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
> -I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
> --sysroot=/usr/src/../obj/destdir.amd64
> -I/usr/src/external/gpl3/gcc/dist/gcc
> -I/usr/src/external/gpl3/gcc/dist/include
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
> -I/usr/src/external/gpl3/gcc/dist/libgcc
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
> -I. -DHAVE_STDLIB_H -DHAVE_STRING_H
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
> -I/usr/src/external/gpl3/gcc/di
> st/gcc/config/i386
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
> -D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/
> dragonfly -Wp,-fno-canonical-system-headers -std=gnu++17
> -fimplicit-templates
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
> mv -f cow-fs_dir.d.tmp cow-fs_dir.d
> In file included from
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/fs_dir.cc:29:10:
> fatal error: bits/largefile-config.h: No such file or directory
>29 | #include
> | ^
> compilation terminated.
> nbmkdep: compile failed.
>
> *** Failed target: cow-fs_dir.d
> *** Failed command: CC=/usr/src/../tools/bin/x86_64--netbsd-c++
> /usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
> -I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
> --sysroot=/usr/src/../obj/destdir.amd64
> -I/usr/src/external/gpl3/gcc/dist/gcc
> -I/usr/src/external/gpl3/gcc/dist/include
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
> -I/usr/src/external/gpl3/gcc/dist/libgcc
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
> -I. -DHAVE_STDLIB_H -DHAVE_STRING_H
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
> -I/usr/src/external/gpl3/gcc/dist/gcc/config/i386
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
> -D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/dragonfly
> -Wp,-fno-canonical-system-headers -std=gnu++17 -fimplicit-templates
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
> mv -f cow-fs_dir.d.tmp cow-fs_dir.d
> *** Error code 1
>
> Stop.
> nbmake[5]: stopped in /usr/src/external/gpl3/gcc/lib/libstdc++-v3
> *** Failed target: dependall-../external/gpl3/gcc/lib/libstdc++-v3
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
> kedirtarget ../external/gpl3/gcc/lib/libstdc++-v3 dependall
> *** Error code 1
>
> *** Failed target: build_install
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
> kedirtarget . dependall-../external/bsd/librtld_db/lib
> dependall-../external/cddl/osnet/lib/libctf
> dependall-../external/public-domain/xz/lib
> dependall-../crypto/external/bsd/netpgp/libmj dep
> endall-../crypto/external/bsd/netpgp/lib/verify
> dependall-../external/bsd/blocklist/lib
> dependall-../external/bsd/elftoolchain/lib/libdwarf
> dependall-../external/mit/lua/lib dependall-libcurs
> es dependall-libdm dependall-libedit dependall-libexecinfo
> dependall-libppath dependall-libperfuse dependall-libquota
> dependall-librefuse dependall-libisns dependall-librumphijack dependall-l
> ibrumpres
current fails to build on amd64
This is with a recent checkout after gcc9 import. If no one can
reproduce this, what can I do?
# create libstdc++-v3/cow-fs_dir.d
CC=/usr/src/../tools/bin/x86_64--netbsd-c++
/usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
-I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
--sysroot=/usr/src/../obj/destdir.amd64
-I/usr/src/external/gpl3/gcc/dist/gcc
-I/usr/src/external/gpl3/gcc/dist/include
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
-I/usr/src/external/gpl3/gcc/dist/libgcc
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
-I. -DHAVE_STDLIB_H -DHAVE_STRING_H
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
-I/usr/src/external/gpl3/gcc/di
st/gcc/config/i386
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
-D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/
dragonfly -Wp,-fno-canonical-system-headers -std=gnu++17
-fimplicit-templates
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
mv -f cow-fs_dir.d.tmp cow-fs_dir.d
In file included from
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/fs_dir.cc:29:10:
fatal error: bits/largefile-config.h: No such file or directory
29 | #include
| ^
compilation terminated.
nbmkdep: compile failed.
*** Failed target: cow-fs_dir.d
*** Failed command: CC=/usr/src/../tools/bin/x86_64--netbsd-c++
/usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
-I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
--sysroot=/usr/src/../obj/destdir.amd64
-I/usr/src/external/gpl3/gcc/dist/gcc
-I/usr/src/external/gpl3/gcc/dist/include
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
-I/usr/src/external/gpl3/gcc/dist/libgcc
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
-I. -DHAVE_STDLIB_H -DHAVE_STRING_H
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
-I/usr/src/external/gpl3/gcc/dist/gcc/config/i386
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
-D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/dragonfly
-Wp,-fno-canonical-system-headers -std=gnu++17 -fimplicit-templates
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
mv -f cow-fs_dir.d.tmp cow-fs_dir.d
*** Error code 1
Stop.
nbmake[5]: stopped in /usr/src/external/gpl3/gcc/lib/libstdc++-v3
*** Failed target: dependall-../external/gpl3/gcc/lib/libstdc++-v3
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
kedirtarget ../external/gpl3/gcc/lib/libstdc++-v3 dependall
*** Error code 1
*** Failed target: build_install
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
kedirtarget . dependall-../external/bsd/librtld_db/lib
dependall-../external/cddl/osnet/lib/libctf
dependall-../external/public-domain/xz/lib
dependall-../crypto/external/bsd/netpgp/libmj dep
endall-../crypto/external/bsd/netpgp/lib/verify
dependall-../external/bsd/blocklist/lib
dependall-../external/bsd/elftoolchain/lib/libdwarf
dependall-../external/mit/lua/lib dependall-libcurs
es dependall-libdm dependall-libedit dependall-libexecinfo
dependall-libppath dependall-libperfuse dependall-libquota
dependall-librefuse dependall-libisns dependall-librumphijack dependall-l
ibrumpres dependall-librumpuser dependall-libnpf
dependall-../crypto/external/bsd/openssl/lib
dependall-../external/bsd/iscsi/lib
dependall-../external/cddl/osnet/lib/libzfs_core dependall-..
/external/cddl/osnet/lib/libzpool dependall-../external/gpl2/lvm2/lib
dependall-../external/gpl3/binutils/lib
dependall-../external/gpl3/gcc/lib/libstdc++-v3
dependall-../external/gpl3/gcc/li
b/libsupc++ dependall-../external/apache2/llvm/include
dependall-../external/mit/libcbor/lib dependall-../external/mit/libuv/lib
*** Error code 1
Stop.
nbmake[3]: stopped in /usr/src/lib
*** Failed target: do-lib
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/usr/src" ;; *) this="${dir}/"; real="/usr/
src/${dir}" ;; esac; show=${this:-.}; echo "${target} ===>
${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@"
Daily NetBSD packages updated to 9.99.73
Hey everybody, The binary package repository I provide of daily pkgsrc trunk builds for NetBSD/amd64 at https://pkgsrc.joyent.com/install-on-netbsd/ has now been switched from 9.99.71 to 9.99.73. For existing users, update /usr/pkg/etc/pkgin/repositories.conf to point to the 9.99.73 directory, or new users can just use the new bootstrap kit provided. New to this bootstrap kit is the inclusion of the pkgsrc-gnupg-keys package, which supplies the pkgsrc-security GPG key to provide out of the box support for "pkg_admin fetch-pkg-vulnerabilities -s". Unfortunately due to http://gnats.netbsd.org/54048 this doesn't actually work with netpgp right now, but that will hopefully be solved at some point. The 9.99.71 repository will no longer be updated, and will eventually be removed. Thanks, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com
Re: ctype and gcc9
On Mon, Sep 21, 2020 at 09:32:08AM +0100, Patrick Welche wrote: > Since gcc9, essentially every ctype using piece of software fails with > >error: array subscript has type 'char' [-Werror=char-subscripts] > > which prompts a style question: cast every argument of every call to > a ctype function in every piece of software to (unsigned char), or > -Wno-error=char-subscripts], or something else? man ctype ... and search for CAVEATS: Because the bugs may manifest as silent misbehavior or as crashes only when fed input outside the US-ASCII range, the NetBSD implementation of the ctype functions is designed to elicit a compiler warning for code that passes inputs of type char in order to flag code that may pass negative values at runtime that would lead to undefined behavior: Martin
Re: ctype and gcc9
Patrick Welche writes: > Since gcc9, essentially every ctype using piece of software fails with > >error: array subscript has type 'char' [-Werror=char-subscripts] > > which prompts a style question: cast every argument of every call to > a ctype function in every piece of software to (unsigned char), or > -Wno-error=char-subscripts], or something else? There were earlier warnings that were similar. This is tricky business! POSIX says (quoting C99, which is harder to give a URL to): https://pubs.opengroup.org/onlinepubs/9699919799/functions/isalpha.html which says that these are functions. However in NetBSD they are macros. I have seen arguments that the macro implementation is legitimate. And, I think a true function would have the same problem, just showing up differently in terms of warnings (promoting char to int in a function call, when the function has UB for many of those values -- a warning less likely to be issued). The caller must provide an int which is representable as unsigned char (or EOF), says the definition, if you read it straightforwardly without trying to be a language lawyer thinking about macros. If you pass a char to a function that takes int, and char is a signed type, and the value is negative, there is sign extension, and thus undefined behavior when using a ctype function. https://wiki.sei.cmu.edu/confluence/display/c/STR34-C.+Cast+characters+to+unsigned+char+before+converting+to+larger+integer+sizes https://wiki.sei.cmu.edu/confluence/display/c/STR37-C.+Arguments+to+character-handling+functions+must+be+representable+as+an+unsigned+char So, it's more than a style question; code that passes char to ctype funtions is actually wrong, and yes it should all be fixed. signature.asc Description: PGP signature
Re: ctype and gcc9
In article <20200921083148.GA17688@quantz>, Patrick Welche wrote: >Since gcc9, essentially every ctype using piece of software fails with > > error: array subscript has type 'char' [-Werror=char-subscripts] > >which prompts a style question: cast every argument of every call to >a ctype function in every piece of software to (unsigned char), or >-Wno-error=char-subscripts], or something else? cast to unsigned char. The ctype functions have undefined behavior for negative values other than -1. The code is buggy. christos
ctype and gcc9
Since gcc9, essentially every ctype using piece of software fails with error: array subscript has type 'char' [-Werror=char-subscripts] which prompts a style question: cast every argument of every call to a ctype function in every piece of software to (unsigned char), or -Wno-error=char-subscripts], or something else? Cheers, Patrick
