daily CVS update output

2019-01-31 Thread NetBSD source update 


Updating src tree:
P src/doc/TODO.compat-module
P src/external/gpl3/gcc/dist/gcc/config.gcc
P src/external/gpl3/gcc/dist/gcc/genemit.c
P src/external/gpl3/gcc/dist/gcc/varasm.c
P src/external/gpl3/gcc/dist/gcc/common/config/riscv/riscv-common.c
P src/external/gpl3/gcc/dist/gcc/config/riscv/constraints.md
cvs update: `src/external/gpl3/gcc/dist/gcc/config/riscv/default-32.h' is no 
longer in the repository
P src/external/gpl3/gcc/dist/gcc/config/riscv/elf.h
P src/external/gpl3/gcc/dist/gcc/config/riscv/generic.md
cvs update: `src/external/gpl3/gcc/dist/gcc/config/riscv/linux-unwind.h' is no 
longer in the repository
P src/external/gpl3/gcc/dist/gcc/config/riscv/linux.h
cvs update: `src/external/gpl3/gcc/dist/gcc/config/riscv/linux64.h' is no 
longer in the repository
cvs update: `src/external/gpl3/gcc/dist/gcc/config/riscv/opcode-riscv.h' is no 
longer in the repository
U src/external/gpl3/gcc/dist/gcc/config/riscv/peephole.md
P src/external/gpl3/gcc/dist/gcc/config/riscv/predicates.md
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv-ftypes.def
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv-modes.def
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv-protos.h
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv.c
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv.h
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv.md
P src/external/gpl3/gcc/dist/gcc/config/riscv/riscv.opt
P src/external/gpl3/gcc/dist/gcc/config/riscv/sync.md
U src/external/gpl3/gcc/dist/libgcc/config/riscv/t-elf
P src/external/gpl3/gcc/dist/libsanitizer/asan/asan_interceptors.cc
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
P src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
P 
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc
P src/external/gpl3/gcc/dist/libsanitizer/ubsan/ubsan_platform.h
P src/external/gpl3/gcc/lib/libgcc/Makefile.inc
U src/external/gpl3/gcc/lib/libgcc/arch/aarch64/gthr-defs.mk
U src/external/gpl3/gcc/lib/libgcc/arch/powerpc/gthr-defs.mk
P src/external/gpl3/gcc/lib/libstdc++-v3/Makefile
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64/defs.mk
P src/external/gpl3/gcc/lib/libsupc++/Makefile.common
P src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64/auto-host.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64/configargs.h
P src/external/gpl3/gcc.old/dist/gcc/common/config/riscv/riscv-common.c
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/constraints.md
cvs update: `src/external/gpl3/gcc.old/dist/gcc/config/riscv/default-32.h' is 
no longer in the repository
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/elf.h
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/generic.md
cvs update: `src/external/gpl3/gcc.old/dist/gcc/config/riscv/linux-unwind.h' is 
no longer in the repository
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/linux.h
cvs update: `src/external/gpl3/gcc.old/dist/gcc/config/riscv/linux64.h' is no 
longer in the repository
cvs update: `src/external/gpl3/gcc.old/dist/gcc/config/riscv/netbsd.h' is no 
longer in the repository
cvs update: `src/external/gpl3/gcc.old/dist/gcc/config/riscv/opcode-riscv.h' is 
no longer in the repository
U src/external/gpl3/gcc.old/dist/gcc/config/riscv/peephole.md
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/predicates.md
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv-ftypes.def
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv-modes.def
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv-protos.h
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv.c
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv.h
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv.md
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/riscv.opt
P src/external/gpl3/gcc.old/dist/gcc/config/riscv/sync.md
U src/external/gpl3/gcc.old/dist/libgcc/config/riscv/t-elf
P src/sys/arch/arm/altera/cycv_platform.c
P src/sys/arch/arm/amlogic/meson_platform.c
P src/sys/arch/arm/fdt/arm_fdtvar.h
P src/sys/arch/arm/fdt/cpu_fdt.c
P src/sys/arch/arm/nvidia/soc_tegra124.c
P src/sys/arch/arm/nvidia/tegra_var.h
P src/sys/arch/arm/samsung/exynos_platform.c
P src/sys/arch/arm/vexpress/vexpress_platform.c
P src/sys/arch/evbarm/fdt/fdt_machdep.c
P src/sys/arch/evbarm/zynq/zynq_machdep.c
P src/sys/arch/x86/x86/pmap.c
P src/sys/compat/netbsd32/netbsd32_module.c
P src/sys/dev/mii/inbmphyreg.h
P src/sys/dev/pci/if_wm.c
P src/sys/dev/pci/if_wmreg.h
P src/sys/dev/raidframe/rf_compat50.c
P src/sys/dev/raidframe/rf_compat50.h
P src/sys/dev/raidframe/rf_compat50_mod.h
P src/sys/dev/raidframe/rf_compat80.c
P src/sys/dev/raidf

Re: debugging symbols and gdb

2019-01-31 Thread Greg A. Woods 
At Thu, 10 Jan 2019 13:28:53 +, Patrick Welche  wrote:
Subject: Re: debugging symbols and gdb
>
>
> # gdb `which Xorg` X.core
> GNU gdb (GDB) 8.0.1
> ...
> Reading symbols from /usr/X11R7/bin/Xorg...Reading symbols from 
> /usr/libdata/debug//usr/X11R7/bin/Xorg.debug...done.
> ...
> Program terminated with signal SIGBUS, Bus error.
> #0  0x7f7fed6ad3e5 in ?? ()
> [Current thread is 1 (process 1)]
> (gdb) bt
> #0  0x7f7fed6ad3e5 in ?? ()
> #1  0x7f7ff3599900 in ?? ()
> #2  0x010100020037 in ?? ()
> #3  0x7f7ff7bd13c0 in ?? ()
> #4  0x0100 in ?? ()
> #5  0x030002000100 in ?? ()
> #6  0x7f7ff400759a in ?? ()
> #7  0x0b000a0009000800 in ?? ()
> #8  0x7f7fdeb8 in ?? ()
> #9  0x7f7fdeb0 in ?? ()
> #10 0x7f7fdea6 in ?? ()
> #11 0x1b001a0019001800 in ?? ()
> #12 0x1f001e001d001c00 in ?? ()
> #13 0x2300220021002000 in ?? ()
> #14 0x2700260025002400 in ?? ()
> #15 0x2b002a0029002800 in ?? ()
> #16 0x7f7ff355b140 in ?? ()
> #17 0x7f7ff35090e0 in ?? ()
> #18 0x000d0011 in ?? ()
> #19 0x20003a0039003800 in ?? ()
> #20 0x in ?? ()

I'm guessing this is a newish GDB bug.

I've been seeing something very similar (on a system running a recent
build of sources from January 14), seemingly at random from one
invocation to another of gdb, when running a static-linked binary from
gdb, i.e. where I would set a backtrace (using the symbol name of a libc
function I wanted to stop on, so the symbol was available before the
run) and then run the program.  If I remember correctly the only
difference is that I would see the symbol name for frame #0.

The first thing I noticed was that the problem would go away and I would
see all the symbol names if I reset debug-file-directory to point at
$DESTDIR/usr/libdata/debug (I don't currently have room on the system to
actually install the debug sets),

Then I noticed the second "Reading symbols from blah.debug...done", i.e.
reading the program's .debug file from the same directory, even without
resetting debug-file-directory.  Further examination of that .debug file
showed it contained all of the missing symbols, so I can't see any
reason for gdb to look elsewhere, and indeed I didn't see it report any
attempts to look elsewhere.  Somehow it was as if changing
debug-file-directory made it use the information it had already loaded.

Sometimes when gdb failed to report symbols I could reset
debug-file-directory and then get symbols, even though they were
presumably already all loaded from the .debug file.  (I always set it to
a valid /usr/libdata/debug hierarchy, so I've no idea if any change
would suffice.)

Also somewhat mysteriously I didn't always see the same number of frames
in the symbol-less output -- and jumping to some middle frame and
backtracing from there would then show even more parent frames, but
never all of them.

I'm in the process of trying to fix a GCC build botch and then rebuild
this system again from most recent sources again, so unfortunately I
can't do a huge amount of further debugging of this issue in quite the
same environment.  However it seems I can sort of demonstrate with the
"cat" and "cat.debug" files from my old OBJDIR, though this shows
something a little different than my first experiences.

Here I first move the cat.debug file aside, then try to load it from
within the session after a breakpoint.  Before loading symbols the
backtrace looks as expected, but after loading them it is completely
broken.  Then I put the cat.debug file back in place, and it is loaded
automatically and everything looks correct.  I am unable to reproduce
the case where the initial backtrace after auto-loading the .debug file
is broken, at least not with this binary.  (Note my attempt to run "cat"
from in the debugger is flawed, but none the less it does result in
hitting the breakpoint as desired for this demo.)  (Note also that in
the last run the extra couple of frames are expected as they are from
inlined functions that are otherwise invisible without debugging
symbols, but in the second backtrace of the first run, after loading
symbols, the frame count is also completely wrong.)

$ file cat
cat: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, 
for NetBSD 8.99.27, not stripped
$ ls -l
total 2528
-rwxr-xr-x  1 woods  wheel  255752 Dec 11 20:18 cat
-rw-r--r--  1 woods  wheel4816 Dec 11 20:18 cat.d
-rwxr-xr-x  1 woods  wheel  932992 Dec 11 20:18 cat.debug
-rw-r--r--  1 woods  wheel   42888 Dec 11 20:18 cat.o
$ mv cat.debug save.debug
$ gdb cat
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration detail

Re: varshm check in postinstall

2019-01-31 Thread Masanobu SAITOH 

On 2019/01/31 18:49, Martin Husemann wrote:

On Thu, Jan 31, 2019 at 05:23:45PM +0900, Masanobu SAITOH wrote:

-   if ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
+   if ${GREP} -E "^var_shm_symlink" "${DEST_DIR}/etc/rc.conf" >/dev/null 
2>&1;
+   then
+   failed=0;
+   elif ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
then
failed=0;
else

OK?


Sounds good!
I always left a commented out /var/shm tmpfs entry in my fstab, but your fix
is better.

Martin


 Done!

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: varshm check in postinstall

2019-01-31 Thread Martin Husemann 
On Thu, Jan 31, 2019 at 05:23:45PM +0900, Masanobu SAITOH wrote:
> - if ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
> + if ${GREP} -E "^var_shm_symlink" "${DEST_DIR}/etc/rc.conf" >/dev/null 
> 2>&1;
> + then
> + failed=0;
> + elif ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
>   then
>   failed=0;
>   else
> 
> OK?

Sounds good!
I always left a commented out /var/shm tmpfs entry in my fstab, but your fix
is better.

Martin

varshm check in postinstall

2019-01-31 Thread Masanobu SAITOH 

 Hi.

 If var_shm_symlink="/tmp/.shm" is in /etc/rc.conf and no /var/shm mount
in /etc/fstab, postinstall complains:

varshm check:
No /var/shm mount found in /etc/fstab

So, I propose the following change:

Index: postinstall
===
RCS file: /cvsroot/src/usr.sbin/postinstall/postinstall,v
retrieving revision 1.221
diff -u -p -r1.221 postinstall
--- postinstall 4 Dec 2018 16:53:44 -   1.221
+++ postinstall 31 Jan 2019 08:22:15 -
@@ -2229,7 +2229,10 @@ do_varshm()
failed=0
 
 	[ -f "${DEST_DIR}/etc/fstab" ] || return 0

-   if ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
+   if ${GREP} -E "^var_shm_symlink" "${DEST_DIR}/etc/rc.conf" >/dev/null 
2>&1;
+   then
+   failed=0;
+   elif ${GREP} -w "/var/shm" "${DEST_DIR}/etc/fstab" >/dev/null 2>&1;
then
failed=0;
else

OK?

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)