Re: CVS commit: src/sys/arch/arm/arm32

2020-11-21 Thread Rin Okuyama

Excellent! Thank you so much for finding out and fixing this!

Full ATF successfully completed for Raspberry Pi 2b, which formerly
crashed due to "anon != NULL && anon->an_ref != 0" panic.

Now, ATF is running on Cubietruck and Raspberry Pi Zero W.

Thanks,
rin

On 2020/11/22 4:44, Nick Hudson wrote:

Module Name:src
Committed By:   skrll
Date:   Sat Nov 21 19:44:52 UTC 2020

Modified Files:
src/sys/arch/arm/arm32: cpuswitch.S

Log Message:
Ensure that r5 contains curlwp before DO_AST_AND_RESTORE_ALIGNMENT_FAULTS
in lwp_trampoline as required by the move to make ASTs operate per-LWP
rather than per-CPU.

Thanks to martin@ for bisecting the amap corruption he was seeing and
testing this fix.


To generate a diff of this commit:
cvs rdiff -u -r1.103 -r1.104 src/sys/arch/arm/arm32/cpuswitch.S

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Re: CVS commit: src/sys

2020-11-12 Thread Erik Fair
Please pull up to netbsd-8 and netbsd-9 release branches.

> On Nov 11, 2020, at 23:44, Simon Burge  wrote:
> 
> Module Name:  src
> Committed By: simonb
> Date: Thu Nov 12 07:44:01 UTC 2020
> 
> Modified Files:
>   src/sys/conf: param.c
>   src/sys/kern: init_main.c
>   src/sys/sys: param.h
> 
> Log Message:
> Set a better default for MAXFILES on larger RAM machines if not
> otherwise specified the kernel config file.  Arbitary numbers are
> 20,000 files for 16GB RAM or more and 10,000 files for 1GB RAM or
> more.
> 
> TODO: Adjust this and other values totally dynamically.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.68 -r1.69 src/sys/conf/param.c
> cvs rdiff -u -r1.532 -r1.533 src/sys/kern/init_main.c
> cvs rdiff -u -r1.678 -r1.679 src/sys/sys/param.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 



Re: CVS commit: src

2020-11-12 Thread Joerg Sonnenberger
On Sun, Nov 08, 2020 at 09:56:48PM +, Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
>   src/external/bsd/kyua-cli: Makefile.inc
>   src/external/ibm-public/postfix: Makefile.inc
>   src/external/public-domain/sqlite: Makefile.inc
>   src/external/public-domain/sqlite/bin: Makefile
>   src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
>   src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support

So the core issue here is that it actually does two separate things. It
does not only enable threadsafety (which is good), but also enables the
worker thread support (which is bad). There is little reason for wanting
the latter in a general build, at least the way it is implemented right
now. Just doing the former is a lot less intrusive...

Joerg
diff -r 2bb2635be785 external/public-domain/sqlite/Makefile.inc
--- a/external/public-domain/sqlite/Makefile.incThu Nov 12 23:24:18 
2020 +0100
+++ b/external/public-domain/sqlite/Makefile.incThu Nov 12 23:28:36 
2020 +0100
@@ -15,6 +15,7 @@
-DHAVE_STRERROR_R=1 \
-DHAVE_USLEEP=1 \
-DHAVE_SYS_ENDIAN_H=1 \
+   -DSQLITE_THREADSAFE \
-DSQLITE_MAX_WORKER_THREADS=0 \
-DSQLITE_ENABLE_COLUMN_METADATA \
-DSQLITE_ENABLE_FTS3_PARENTHESIS \


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/13 2:35, nia wrote:

I'll revert the commit shortly.


Thank you very much for your quick response.


I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.


Yeah, this is why we need tests, and also listen to others before
making somewhat big changes. No one is perfect...

Thanks,
rin


Re: CVS commit: src

2020-11-12 Thread Martin Husemann
On Thu, Nov 12, 2020 at 07:58:13PM +, Taylor R Campbell wrote:
> But there's a snag with heimdal.
> 
> Heimdal exposes the sqlite3 library to clients via libgssapi.so which
> links against libkrb5.so which brings in libsqlite3.so.  So we get nice
> situations like this:
> 
> % ldd /pkg/2020Q2/bin/svn | grep sqlite   
> -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0
> -lsqlite3.1 => /usr/lib/libsqlite3.so.1
> 
> This is also why the change to base sqlite3 affected, e.g., su(1).

How about making sqlite3 just a private lib statically linked into whatever
part of heimdahl actually needs it, and not exposing any symbols from it?

Martin


Re: CVS commit: src

2020-11-12 Thread Taylor R Campbell
> Date: Thu, 12 Nov 2020 11:21:43 -0800
> From: Jason Thorpe 
> 
> > On Nov 12, 2020, at 9:40 AM, nia  wrote:
> > 
> > For the record I'm just trying to fix things so that running
> > third-party software on NetBSD sucks less. If fewer third-party
> > libraries were exposed by the base system this wouldn't be
> > necessary.
> 
> Why do we even have sqlite in the base system in the first place?

apropos(1); a handful of other things also use it (heimdal, postfix).

I suggested that we leave the bells & whistles out of base sqlite3,
maybe even stop installing the .so symlink, and teach pkgsrc to just
use pkgsrc sqlite3 (with all bells & whistles included) rather than
base sqlite3 -- after all, sqlite3 is meant to be embedded and has
lots of optional bells & whistles that apropos(1) has no need of, so
it is silly to impose those costs on apropos(1) or make sqlite3 part
of the NetBSD API.

But there's a snag with heimdal.

Heimdal exposes the sqlite3 library to clients via libgssapi.so which
links against libkrb5.so which brings in libsqlite3.so.  So we get nice
situations like this:

% ldd /pkg/2020Q2/bin/svn | grep sqlite   
-lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0
-lsqlite3.1 => /usr/lib/libsqlite3.so.1

This is also why the change to base sqlite3 affected, e.g., su(1).

I have no idea what heimdal does with sqlite3, but it puts us in a
pretty pickle: we can't reliably use pkgsrc sqlite3 on existing NetBSD
installs for packages that use gssapi, and we can't rely on sqlite3 in
existing NetBSD installs for packages that need newer/threaded/jsonned
sqlite3 as we often encounter.


Re: CVS commit: src

2020-11-12 Thread Jason Thorpe


> On Nov 12, 2020, at 9:40 AM, nia  wrote:
> 
> For the record I'm just trying to fix things so that running
> third-party software on NetBSD sucks less. If fewer third-party
> libraries were exposed by the base system this wouldn't be
> necessary.

Why do we even have sqlite in the base system in the first place?

-- thorpej



Re: CVS commit: src

2020-11-12 Thread nia
On Thu, Nov 12, 2020 at 05:35:44PM +, nia wrote:
> I'll revert the commit shortly.
> 
> I wasn't expecting such major breakage (obviously) and actually
> did run a build but ran into different problems with libstdc++.

For the record I'm just trying to fix things so that running
third-party software on NetBSD sucks less. If fewer third-party
libraries were exposed by the base system this wouldn't be
necessary.


Re: CVS commit: src

2020-11-12 Thread nia
I'll revert the commit shortly.

I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/12 23:03, Rin Okuyama wrote:

The backtrace reads:

| (gdb) bt
| #0  0xfc2961bca308 in ?? ()
| #1  0xfc2961b9ec10 in __deregister_frame_info_bases ()
|    from /usr/lib/libgcc_s.so.1
| #2  0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
| addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514
| ...

The fault address is anon memory w/o exec permission when su exits:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write    /altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BE6000 40K read/write  [ anon ]
| ...


Oops, correction: the fault address is not mapped when su exits;
FC2961BB6000 + 40K = FC2961BC.

The discussion thereafter does not change.

Thanks,
rin


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/11 1:50, nia wrote:

On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:

Module Name:src
Committed By:   nia
Date:   Sun Nov  8 21:56:48 UTC 2020

Modified Files:
 src/external/bsd/kyua-cli: Makefile.inc
 src/external/ibm-public/postfix: Makefile.inc
 src/external/public-domain/sqlite: Makefile.inc
 src/external/public-domain/sqlite/bin: Makefile
 src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
 src/usr.sbin/makemandb: Makefile

Log Message:
sqlite: do not build without multithreading support

at least a few pkgsrc packages avoid base sqlite because it fails
this check, and it's probably a surprising performance penalty for
unsuspecting users


Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
have pkgsrc always use pkgsrc sqlite3, and change base to go back to
the smaller non-threaded sqlite3 with only the options the things in
base actually need?

Also: What is the performance penalty?  The sqlite3 documentation
(https://www.sqlite.org/faq.html#q6) suggests that _enabling_
SQLITE_THREADSAFE has a performance penalty, not the other way around.

It seems to me we've had a lot of problems over the years trying to
use base sqlite3 for everything in pkgsrc.  It's not clear to me that
any of the recent changes are helpful for the three things in base
that need sqlite3, and it's also not clear that they will help with
running newer pkgsrc on older NetBSD.


libevent is also problematic. Maybe there's just too many third-party
libraries that are exposed that sholdn't be.


A failure for cvs, suspected to be a fallout of threaded sqlite3 was
reported in port-arm@. See thread starts with:

http://mail-index.netbsd.org/port-arm/2020/11/12/msg007046.html

Also, I encountered another fallout: ``su -'' receives SIGSEGV when exits
(on aarch64, but I bet this is MI problem):

| $ su
| # exit
| $ su -
| # exit
| [2]   Segmentation fault (core dumped) su -

The backtrace reads:

| (gdb) bt
| #0  0xfc2961bca308 in ?? ()
| #1  0xfc2961b9ec10 in __deregister_frame_info_bases ()
|from /usr/lib/libgcc_s.so.1
| #2  0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
| addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514
| ...

The fault address is anon memory w/o exec permission when su exits:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write/altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BE6000 40K read/write  [ anon ]
| ...

However, when su is running, libpthread is loaded at this address:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write/altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BC 76K read/exec /altroot/lib/libpthread.so.1.4
| FC2961BD3000 64K   /altroot/lib/libpthread.so.1.4
| ...

su is not explicitly linked to libpthread, but it is loaded via libkrb5
via libpam. It registers its own deconstructor, however, it is unloaded
before su exits. Then, SIGSEGV takes place as a result.

IMO, this commit should be reverted ASAP. This kind of change needs more
tests, and discussion in appropriate lists before commit. Unfortunately,
the committer did not even carry out ``build.sh'' before commit (martin
fixed the build failure due to this). This is not what we, at least, I
expect our developers.

Thanks,
rin


Re: CVS commit: src/sys/arch/arm/arm

2020-11-11 Thread Rin Okuyama

On 2020/11/12 6:52, matthew green wrote:

"Rin Okuyama" writes:

Module Name:src
Committed By:   rin
Date:   Tue Nov 10 21:40:07 UTC 2020

Modified Files:
src/sys/arch/arm/arm: cpu_exec.c

Log Message:
Test (epp->ep_esch->es_emul != _netbsd) instead of


nice, this is a step forward.

an optimisation on it could be to remove this test entirely
if neither MODULAR or COMAPT_NETBSD32 are set, as it will
always be false there.


Ah, yes. I will commit after some test. Thanks!

rin


re: CVS commit: src/sys/arch/arm/arm

2020-11-11 Thread matthew green
"Rin Okuyama" writes:
> Module Name:  src
> Committed By: rin
> Date: Tue Nov 10 21:40:07 UTC 2020
>
> Modified Files:
>   src/sys/arch/arm/arm: cpu_exec.c
>
> Log Message:
> Test (epp->ep_esch->es_emul != _netbsd) instead of

nice, this is a step forward.

an optimisation on it could be to remove this test entirely
if neither MODULAR or COMAPT_NETBSD32 are set, as it will
always be false there.

thanks.


.mrg.


Re: CVS commit: src

2020-11-10 Thread nia
On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By:   nia
> > Date:   Sun Nov  8 21:56:48 UTC 2020
> > 
> > Modified Files:
> > src/external/bsd/kyua-cli: Makefile.inc
> > src/external/ibm-public/postfix: Makefile.inc
> > src/external/public-domain/sqlite: Makefile.inc
> > src/external/public-domain/sqlite/bin: Makefile
> > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
> > src/usr.sbin/makemandb: Makefile
> > 
> > Log Message:
> > sqlite: do not build without multithreading support
> > 
> > at least a few pkgsrc packages avoid base sqlite because it fails
> > this check, and it's probably a surprising performance penalty for
> > unsuspecting users
> 
> Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
> have pkgsrc always use pkgsrc sqlite3, and change base to go back to
> the smaller non-threaded sqlite3 with only the options the things in
> base actually need?
> 
> Also: What is the performance penalty?  The sqlite3 documentation
> (https://www.sqlite.org/faq.html#q6) suggests that _enabling_
> SQLITE_THREADSAFE has a performance penalty, not the other way around.
> 
> It seems to me we've had a lot of problems over the years trying to
> use base sqlite3 for everything in pkgsrc.  It's not clear to me that
> any of the recent changes are helpful for the three things in base
> that need sqlite3, and it's also not clear that they will help with
> running newer pkgsrc on older NetBSD.

libevent is also problematic. Maybe there's just too many third-party
libraries that are exposed that sholdn't be.


Re: CVS commit: src

2020-11-10 Thread Taylor R Campbell
> Module Name:src
> Committed By:   nia
> Date:   Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
> src/external/public-domain/sqlite: Makefile.inc
> src/external/public-domain/sqlite/bin: Makefile
> src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
> src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support
> 
> at least a few pkgsrc packages avoid base sqlite because it fails
> this check, and it's probably a surprising performance penalty for
> unsuspecting users

Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
have pkgsrc always use pkgsrc sqlite3, and change base to go back to
the smaller non-threaded sqlite3 with only the options the things in
base actually need?

Also: What is the performance penalty?  The sqlite3 documentation
(https://www.sqlite.org/faq.html#q6) suggests that _enabling_
SQLITE_THREADSAFE has a performance penalty, not the other way around.

It seems to me we've had a lot of problems over the years trying to
use base sqlite3 for everything in pkgsrc.  It's not clear to me that
any of the recent changes are helpful for the three things in base
that need sqlite3, and it's also not clear that they will help with
running newer pkgsrc on older NetBSD.


Re: CVS commit: src/share/mk

2020-11-09 Thread Rin Okuyama

On 2020/11/10 1:15, Christos Zoulas wrote:

- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
   file, instead of writing directly to ${.TARGET} and then overwriting
   ${.TARGET} with ctfconvert. This avoids build failures after a build
   got interrupted (the "partially built from C" scourge).


Thanks, I wanted this!

rin


Re: CVS commit: src

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 22:56, Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
>   src/external/bsd/kyua-cli: Makefile.inc
>   src/external/ibm-public/postfix: Makefile.inc
>   src/external/public-domain/sqlite: Makefile.inc
>   src/external/public-domain/sqlite/bin: Makefile
>   src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
>   src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support
> 
> at least a few pkgsrc packages avoid base sqlite because it fails
> this check, and it's probably a surprising performance penalty for
> unsuspecting users
> 

I'm getting:

dependall ===> usr.sbin/makemandb
nbmake[6]: nbmake[6]: don't know how to make -ltermlib. Stop
nbmake[6]: stopped in /usr/src/usr.sbin/makemandb



signature.asc
Description: OpenPGP digital signature


Re: catman (Was: CVS commit: src/games/fortune/datfiles)

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 23:20, Valery Ushakov wrote:
> It's (partially) past-tensed, which looks stupid and cripples the
> joke.

catman has zero to do with current UNIX or any other standard I checked
(SVID, XPG, POSIX, XNS, SUS, ISO, ANSI). It was a historical utility.
I've changed it to be relatively accurate for a historical reference to
Unix/BSD. I object to calling it a current Unix thing and suggesting to
users that they can find it in section 8.

If catman(8) is still delivered somewhere, it is documenting a dead toy.

On 09.11.2020 01:05, Thomas Klausner wrote:
> On Mon, Nov 09, 2020 at 12:46:42AM +0300, Valeriy E. Ushakov wrote:
>> Also, come to think of it... Removing catman (i.e. user's ability to
>> generate cat pages) is rather different from removing MKCATPAGES,
>> what's going on here?
> 
> I asked kamil about something else on this topic and he mentioned
> catman.  On reading the man pages I didn't really see a reason for it
> to stay if we remove the cat pages completely.
> 
> Do you see it differently? If yes, why?
>  Thomas
> 

catman is still reachable for users (I still have no evidence that I was
not the last user of .cat pages in NetBSD) that really want it in
contrib/ of mandoc, but out of the distribution.

I'm still test-building the final removal and I will land it once I feel
comfortable about it.



signature.asc
Description: OpenPGP digital signature


Re: catman (Was: CVS commit: src/games/fortune/datfiles)

2020-11-08 Thread Thomas Klausner
On Mon, Nov 09, 2020 at 12:46:42AM +0300, Valeriy E. Ushakov wrote:
> Also, come to think of it... Removing catman (i.e. user's ability to
> generate cat pages) is rather different from removing MKCATPAGES,
> what's going on here?

I asked kamil about something else on this topic and he mentioned
catman.  On reading the man pages I didn't really see a reason for it
to stay if we remove the cat pages completely.

Do you see it differently? If yes, why?
 Thomas


Re: catman (Was: CVS commit: src/games/fortune/datfiles)

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 22:46, Valery Ushakov wrote:
> On Sun, Nov 08, 2020 at 17:37:30 +, Kamil Rytarowski wrote:
> 
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Nov  8 17:37:30 UTC 2020
>>
>> Modified Files:
>>  src/games/fortune/datfiles: fortunes
>>
>> Log Message:
>> catman(8) is a past thing
> 
> Please, revert this.  It's completely irrelevant for the joke if
> netbsd ships catman or not.
> 
> Also, come to think of it... Removing catman (i.e. user's ability to
> generate cat pages) is rather different from removing MKCATPAGES,
> what's going on here?
> 
> -uwe
> 

catman(8) is to removed soon as discussed with wiz@.

The fortune is still there, it's not removed.



signature.asc
Description: OpenPGP digital signature


catman (Was: CVS commit: src/games/fortune/datfiles)

2020-11-08 Thread Valery Ushakov
On Sun, Nov 08, 2020 at 17:37:30 +, Kamil Rytarowski wrote:

> Module Name:  src
> Committed By: kamil
> Date: Sun Nov  8 17:37:30 UTC 2020
> 
> Modified Files:
>   src/games/fortune/datfiles: fortunes
> 
> Log Message:
> catman(8) is a past thing

Please, revert this.  It's completely irrelevant for the joke if
netbsd ships catman or not.

Also, come to think of it... Removing catman (i.e. user's ability to
generate cat pages) is rather different from removing MKCATPAGES,
what's going on here?

-uwe


Re: CVS commit: src

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 17:55, Christos Zoulas wrote:
> In article <20201108145236.3a009f...@cvs.netbsd.org>,
> Kamil Rytarowski  wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Nov  8 14:52:36 UTC 2020
>>
>> Modified Files:
>>  src: BUILDING
>>  src/distrib/sets: sets.subr
>>  src/doc: BUILDING.mdoc
>>  src/share/man/man5: mk.conf.5
>>  src/share/mk: bsd.README bsd.man.mk bsd.own.mk
>>
>> Log Message:
>> Remove the support for MKCATPAGES
>>
>> It was optional since 1999 and disabled by default since 2012.
>>
>> Proposed on tech-userlevel@.
> 
> What about the sets?
> 
> christos
> 

I'm test-building a local patch removing the cat files, directories and
a few other remnants.

Once it will be done, I will land it.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src

2020-11-08 Thread Christos Zoulas
In article <20201108145236.3a009f...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Sun Nov  8 14:52:36 UTC 2020
>
>Modified Files:
>   src: BUILDING
>   src/distrib/sets: sets.subr
>   src/doc: BUILDING.mdoc
>   src/share/man/man5: mk.conf.5
>   src/share/mk: bsd.README bsd.man.mk bsd.own.mk
>
>Log Message:
>Remove the support for MKCATPAGES
>
>It was optional since 1999 and disabled by default since 2012.
>
>Proposed on tech-userlevel@.

What about the sets?

christos



Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

Thanks for checking!

I agree with your proposed changes.  If noone else objects, please
go ahead and commit.


On Sun, 8 Nov 2020, Rin Okuyama wrote:


Thanks Paul for finding out the bug!

Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.

However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.

By fixing them, OABI binaries work and dump valid core files!

I changed two files.

(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c

Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.

(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c

This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.

I will commit them soon if there's no objection.

Thanks,
rin

On 2020/11/08 6:53, Paul Goyette wrote:

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.?? This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile


.if ${MACHINE_ARCH} == "arm"
.PATH:?? ${S}/arch/arm/arm32
SRCS+=?? netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.?? But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

?? modload compat_netbsd32
?? modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

?? #include 
?? int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD?? 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov?? 5 20:26:39 JST 
2020 rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[?? 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_vm_default_addr' not found
[?? 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_machdep_md_init' not found
[?? 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_sendsig' not found
[?? 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_mcontext32_validate' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_setmcontext32' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_machdep_md_fini' not found
[?? 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `startlwp32' not found
[?? 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_getmcontext32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `machine32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_sysarch' not found
[?? 29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in 
files

not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin






++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail 
addresses: |
| (Retired)?? | FA29 0E3B 35AF E8AE 6651 | 
p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org 
|

++--+---+





++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail 
addresses: |
| 

Re: CVS commit: src/sys

2020-11-07 Thread Rin Okuyama

Thanks Paul for finding out the bug!

Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.

However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.

By fixing them, OABI binaries work and dump valid core files!

I changed two files.

(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c

Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.

(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c

This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.

I will commit them soon if there's no objection.

Thanks,
rin

On 2020/11/08 6:53, Paul Goyette wrote:

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile

.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

    modload compat_netbsd32
    modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

    #include 
    int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile

.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

#include 
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


re: CVS commit: src/sys

2020-11-07 Thread matthew green
>   .if ${MACHINE_ARCH} == "arm"

this is wrong.  it should use MACHINE_CPU.


.mrg.


Re: CVS commit: src/sys

2020-11-07 Thread Christos Zoulas
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos

> On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:
> 
> OK, I think I found the problem, but I don't know how to solve it...
> 
> All of the undefined symbols are supposed to be provided by
> 
>   .../sys/arch/arm/arm32/netbsd32_machdep.c
> 
> but there is no netbsd32_machdep.o included in the compat_netbsd32
> module.  This file should be included by the following code in 
> .../sys/modules/compat_netbsd32/Makefile
> 
>   .if ${MACHINE_ARCH} == "arm"
>   .PATH:  ${S}/arch/arm/arm32
>   SRCS+=  netbsd32_machdep.c
>   .endif
> 
> but it seems not to work (or at least, it doesn't do what it was
> intended to do).
> 
> 
> 
> 
> 
> 
> On Thu, 5 Nov 2020, Rin Okuyama wrote:
> 
>> On 2020/11/05 5:43, Paul Goyette wrote:
>>> BTW, the patch you submitted with the initial message in this thread
>>> looks good for avoiding the issue.  But I'm not sure it is a complete
>>> solution.
>>> In particular, you would need to build a 32-bit arm that contains ``no
>>> options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
>>> and compat_netbsd32_coredump modules
>>> 
>>> modload compat_netbsd32
>>> modload compat_netbsd32_coredump
>>> Then see if emulation of the old ABI still works, and check if core-
>>> dump works for old-ADI programs; the test program I've been using for
>>> core-dump checking is
>>> 
>>> #include 
>>> int main(int argc, void *argv) { abort(); }
>>> I really have to leave and take care of some personal business, so I
>>> would greatly appreciate if you can check this out.
>> 
>> Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
>> 
>> 
>> # uname -ap
>> NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
>> rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
>> # modload compat_netbsd32
>> [  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_vm_default_addr' not found
>> [  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_machdep_md_init' not found
>> [  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_sendsig' not found
>> [  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_mcontext32_validate' not found
>> [  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_setmcontext32' not found
>> [  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_machdep_md_fini' not found
>> [  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `startlwp32' not found
>> [  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_getmcontext32' not found
>> [  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `machine32' not found
>> [  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_sysarch' not found
>> [  29.7318320] WARNING: module error: unable to affix module 
>> `compat_netbsd32', error 8
>> modload: compat_netbsd32: Exec format error
>> 
>> 
>> This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
>> not included in compat_netbsd32 module. compat_netbsd32 module must not
>> work also for aarch64 and mips64 for the same reason, whereas amd64 and
>> sparc64 seem OK.
>> 
>> Thanks,
>> rin
>> 
>> !DSPAM:5fa3f309175521945872603!
>> 
>> 
> 
> ++--+---+
> | Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
> | (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
> ++--+---+



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile


.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-05 Thread Rin Okuyama

On 2020/11/05 23:07, Paul Goyette wrote:

I will investigate.


Thanks!


Can you confirm that it works correctly if you have the built-in
module?  (ie, kernel with ``options COMPAT_NETBSD32'')


Yes, it works fine.

rin


Re: CVS commit: src/sys

2020-11-05 Thread Paul Goyette

I will investigate.

Can you confirm that it works correctly if you have the built-in
module?  (ie, kernel with ``options COMPAT_NETBSD32'')


On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-05 Thread Rin Okuyama

On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020  
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin


Re: CVS commit: src/sys/kern

2020-11-05 Thread Rin Okuyama

On 2020/11/05 2:45, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> options    PTRACE  # Include ptrace(2) syscall
###> options    PTRACE_HOOKS    # Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187 int error;
   188
   189 switch (cmd) {
   190 case MODULE_CMD_INIT:
   191 error = syscall_establish(_netbsd, ptrace_syscalls);
   192 break;
   193 case MODULE_CMD_FINI:
   194 error = syscall_disestablish(_netbsd, ptrace_syscalls);
   195 break;
   196 default:
   197 error = ENOTTY;
   198 break;
   199 }
   200 return error;
   201 }


Yes that would be a problem.


Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.


I have some prior obligations, so I won't be able to look at this
until this evening.

Thanks for the detailed analysis.


Fixed. Thanks!

rin


Re: CVS commit: src/sys

2020-11-04 Thread Paul Goyette

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

modload compat_netbsd32
modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

#include 
int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.

Thanks!



On Wed, 4 Nov 2020, Paul Goyette wrote:


I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.

Christos, can you help out on this?



On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

	panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70


Does the attached patch seem reasonable to you?

Thanks,
rin





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

!DSPAM:5fa2ae10252946113815662!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

OK, this is my mistake.  When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h).  I will commit this shortly, before I leave.

Thanks for the "recipe" for reproducing the problem - I will try it 
later when I return.



On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187  int error;
   188
   189  switch (cmd) {
   190  case MODULE_CMD_INIT:
   191 		error = syscall_establish(_netbsd, 
ptrace_syscalls);

   192  break;
   193  case MODULE_CMD_FINI:
   194 		error = syscall_disestablish(_netbsd, 
ptrace_syscalls);

   195  break;
   196  default:
   197  error = ENOTTY;
   198  break;
   199  }
   200  return error;
   201 }

Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 
'gdb_exception_RETURN_MASK_ERROR'

[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.

Thanks,
rin

!DSPAM:5fa2b869233318156490363!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187  int error;
   188
   189  switch (cmd) {
   190  case MODULE_CMD_INIT:
   191 		error = syscall_establish(_netbsd, 
ptrace_syscalls);

   192  break;
   193  case MODULE_CMD_FINI:
   194 		error = syscall_disestablish(_netbsd, 
ptrace_syscalls);

   195  break;
   196  default:
   197  error = ENOTTY;
   198  break;
   199  }
   200  return error;
   201 }


Yes that would be a problem.


Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 
'gdb_exception_RETURN_MASK_ERROR'

[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.


I have some prior obligations, so I won't be able to look at this
until this evening.

Thanks for the detailed analysis.



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Rin Okuyama

On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd, 
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd, 
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }

Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-04 Thread Jason Thorpe



> On Nov 4, 2020, at 5:33 AM, Paul Goyette  wrote:
> 
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.

In this particular case, it's for the old 32-bit ABI that predates the EABI 
standard the ARM port now uses.

-- thorpej



Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/kern

2020-11-04 Thread Rin Okuyama

On 2020/11/04 22:31, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:    src
Committed By:    pgoyette
Date:    Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-04 Thread Martin Husemann
On Wed, Nov 04, 2020 at 05:33:29AM -0800, Paul Goyette wrote:
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.

(At least) mips and arm have various 32bit ABIs that are handled by
COMPAT_NETBSD32.

Martin


Re: CVS commit: src/sys

2020-11-04 Thread Paul Goyette

I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.

Christos, can you help out on this?



On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

	panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70


Does the attached patch seem reasonable to you?

Thanks,
rin


!DSPAM:5fa25cf9259143308188765!


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-03 Thread Rin Okuyama

Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70

Does the attached patch seem reasonable to you?

Thanks,
rin
Index: sys/compat/netbsd32/netbsd32_core.c
===
RCS file: /home/netbsd/src/sys/compat/netbsd32/netbsd32_core.c,v
retrieving revision 1.16
diff -p -u -r1.16 netbsd32_core.c
--- sys/compat/netbsd32/netbsd32_core.c 1 Nov 2020 18:51:02 -   1.16
+++ sys/compat/netbsd32/netbsd32_core.c 4 Nov 2020 06:52:52 -
@@ -68,11 +68,15 @@ compat_netbsd32_coredump_modcmd(modcmd_t
switch (cmd) {
case MODULE_CMD_INIT:
MODULE_HOOK_SET(coredump_netbsd32_hook, real_coredump_netbsd32);
+#ifdef _LP64
MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
+#endif
return 0;
case MODULE_CMD_FINI:
MODULE_HOOK_UNSET(coredump_netbsd32_hook);
+#ifdef _LP64
MODULE_HOOK_UNSET(coredump_elf32_hook);
+#endif
return 0;
default:
return ENOTTY;


Re: CVS commit: src/sys/kern

2020-11-03 Thread Rin Okuyama

Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-01 Thread Paul Goyette

On Sun, 1 Nov 2020, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


Of course, this should be "Welcome to 9.99.75"

:)

++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Christos Zoulas
I've asked.

Best,

christos

> On Nov 1, 2020, at 11:19 AM, Kimmo Suominen  wrote:
> 
>> Log Message:
>> CHANGED FROM 3.1b TO 3.1c
>> 
>> * Do not write after the end of the array and overwrite the stack when
>>  colon-separated SGR sequences contain empty arguments.
> 
> Pullup to -9 and -8 for security fix?
> 
> https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Kimmo Suominen
> Log Message:
> CHANGED FROM 3.1b TO 3.1c
> 
> * Do not write after the end of the array and overwrite the stack when
>   colon-separated SGR sequences contain empty arguments.

Pullup to -9 and -8 for security fix?

https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html



Re: CVS commit: src

2020-10-28 Thread David H. Gutteridge
On Wed, 2020-10-28 at 11:56 +, nia wrote:
> On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > > i can have a look at mate-applets tomorrow, the current code looks
> > > like it won't work with AMD CPUs on netbsd-9 and that should
> > > ideally
> > > be fixed.
> > 
> > Yeah, that's my understanding. (I'm guessing Youri only had Intel
> > hardware to test with, which was also true for me until recently.
> 
> i actually can't get the mate-applets cpufreq thing to work at all,
> it keeps thinking my CPU is running at 2 MHz. was it working for
> you before the change?

I just tried it with 9.99.72 from September (on an Intel i5-3340M), and
I get the same bogus "2 MHz" value reported. I'd thought it had worked
at some point in the past, but maybe I'm misremembering. (I don't
normally use mate-applets myself; I only test it if I'm updating MATE
packages to a new version. I'd remembered the code in question from
looking through it some time ago.)

Dave




Re: CVS commit: src

2020-10-28 Thread nia
On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > i can have a look at mate-applets tomorrow, the current code looks
> > like it won't work with AMD CPUs on netbsd-9 and that should ideally
> > be fixed.
> 
> Yeah, that's my understanding. (I'm guessing Youri only had Intel
> hardware to test with, which was also true for me until recently.

i actually can't get the mate-applets cpufreq thing to work at all,
it keeps thinking my CPU is running at 2 MHz. was it working for
you before the change?


Re: CVS commit: src

2020-10-27 Thread David H. Gutteridge
On Tue, 2020-10-27 at 19:54 +, nia wrote:
> On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> > On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> > > On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> > > > this doesn't seem like the right design.  we have cpus
> > > > already that have multiple frequency domains, so this
> > > > doesn't work with that setup, so attempt to use it as a
> > > > general method for estd etc seems limited and thsu not
> > > > the right method.
> > > > 
> > > > eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> > > > 4 slow and 2 fast cores it has, and they have both
> > > > separate controls as well as list of available freqs:
> > > > 
> > > > machdep.cpufreq.cpu0.target = 1416
> > > > machdep.cpufreq.cpu0.current = 1416
> > > > machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> > > > machdep.cpufreq.cpu4.target = 1800
> > > > machdep.cpufreq.cpu4.current = 1800
> > > > machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816
> > > > 600 408
> > > > 
> > > 
> > > yeah, i'm aware of this, my intent was really only to normalize
> > > the variables that didn't have multi-cpu-domain support (since
> > > those are already normalized as rk3399)
> > > 
> > > do you think we should use the same variable and tie things to
> > > under cpu0 when there isn't support for scaling independent CPUs?
> > > 
> > > > additionally, if we are going to design a "good" API for
> > > > this, it should publish things outside of "machdep".
> > > > i'd go with hw.cpufreq probbaly.
> > > > 
> > > > (i didn't look, but it sure would be annoying if the old
> > > > nodes that have existed for over a decade were changed
> > > > and any other 3rd party code or scrip tis now broken.)
> > > 
> > > i actually picked this name because it was already in use and
> > > thus already checked by estd.
> > > 
> > > i agree it should go outside machdep, but i didn't want
> > > to break existing code.
> > 
> > This has impacted youri@'s NetBSD frequency handling patches in x11/
> > mate-applets, which only make references using
> > "machdep.est.frequency"
> > at present.
> > 
> > Since this change removes pre-existing sysctl nodes, shouldn't this
> > merit a kernel version bump? It potentially breaks things in user-
> > space. (I see from the mailing list archives that Mouse asked about
> > the idea of retaining old names for compatibility.)
> > 
> > (Now, the mate-applets situation could be improved by the new,
> > generic
> > means of exposing this information. martin@ had asked for non-x86
> > support in PR pkg/53975, one of the barriers being I imagine few
> > people
> > have the hardware to test with. I don't.)
> > 
> > Dave
> > 
> > 
> 
> i can have a look at mate-applets tomorrow, the current code looks
> like it won't work with AMD CPUs on netbsd-9 and that should ideally
> be fixed.

Yeah, that's my understanding. (I'm guessing Youri only had Intel
hardware to test with, which was also true for me until recently.)

> i thought kernel versions were specifically about module
> compatibility.

That may be the case, that was a question for any kernel developers at
large. :)

Dave




Re: CVS commit: src

2020-10-27 Thread nia
On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> >> this doesn't seem like the right design.  we have cpus
> >> already that have multiple frequency domains, so this
> >> doesn't work with that setup, so attempt to use it as a
> >> general method for estd etc seems limited and thsu not
> >> the right method.
> >> 
> >> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> >> 4 slow and 2 fast cores it has, and they have both
> >> separate controls as well as list of available freqs:
> >> 
> >> machdep.cpufreq.cpu0.target = 1416
> >> machdep.cpufreq.cpu0.current = 1416
> >> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> >> machdep.cpufreq.cpu4.target = 1800
> >> machdep.cpufreq.cpu4.current = 1800
> >> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
> >>
> >
> >yeah, i'm aware of this, my intent was really only to normalize
> >the variables that didn't have multi-cpu-domain support (since
> >those are already normalized as rk3399)
> >
> >do you think we should use the same variable and tie things to
> >under cpu0 when there isn't support for scaling independent CPUs?
> >
> >> additionally, if we are going to design a "good" API for
> >> this, it should publish things outside of "machdep".
> >> i'd go with hw.cpufreq probbaly.
> >> 
> >> (i didn't look, but it sure would be annoying if the old
> >> nodes that have existed for over a decade were changed
> >> and any other 3rd party code or scrip tis now broken.)
> >
> >i actually picked this name because it was already in use and
> >thus already checked by estd.
> >
> >i agree it should go outside machdep, but i didn't want
> >to break existing code.
> 
> This has impacted youri@'s NetBSD frequency handling patches in x11/
> mate-applets, which only make references using "machdep.est.frequency"
> at present.
> 
> Since this change removes pre-existing sysctl nodes, shouldn't this
> merit a kernel version bump? It potentially breaks things in user-
> space. (I see from the mailing list archives that Mouse asked about
> the idea of retaining old names for compatibility.)
> 
> (Now, the mate-applets situation could be improved by the new, generic
> means of exposing this information. martin@ had asked for non-x86
> support in PR pkg/53975, one of the barriers being I imagine few people
> have the hardware to test with. I don't.)
> 
> Dave
> 
>

i can have a look at mate-applets tomorrow, the current code looks
like it won't work with AMD CPUs on netbsd-9 and that should ideally
be fixed.

i thought kernel versions were specifically about module compatibility.


Re: CVS commit: src

2020-10-27 Thread David H. Gutteridge
On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
>On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
>> this doesn't seem like the right design.  we have cpus
>> already that have multiple frequency domains, so this
>> doesn't work with that setup, so attempt to use it as a
>> general method for estd etc seems limited and thsu not
>> the right method.
>> 
>> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
>> 4 slow and 2 fast cores it has, and they have both
>> separate controls as well as list of available freqs:
>> 
>> machdep.cpufreq.cpu0.target = 1416
>> machdep.cpufreq.cpu0.current = 1416
>> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
>> machdep.cpufreq.cpu4.target = 1800
>> machdep.cpufreq.cpu4.current = 1800
>> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
>>
>
>yeah, i'm aware of this, my intent was really only to normalize
>the variables that didn't have multi-cpu-domain support (since
>those are already normalized as rk3399)
>
>do you think we should use the same variable and tie things to
>under cpu0 when there isn't support for scaling independent CPUs?
>
>> additionally, if we are going to design a "good" API for
>> this, it should publish things outside of "machdep".
>> i'd go with hw.cpufreq probbaly.
>> 
>> (i didn't look, but it sure would be annoying if the old
>> nodes that have existed for over a decade were changed
>> and any other 3rd party code or scrip tis now broken.)
>
>i actually picked this name because it was already in use and
>thus already checked by estd.
>
>i agree it should go outside machdep, but i didn't want
>to break existing code.

This has impacted youri@'s NetBSD frequency handling patches in x11/
mate-applets, which only make references using "machdep.est.frequency"
at present.

Since this change removes pre-existing sysctl nodes, shouldn't this
merit a kernel version bump? It potentially breaks things in user-
space. (I see from the mailing list archives that Mouse asked about
the idea of retaining old names for compatibility.)

(Now, the mate-applets situation could be improved by the new, generic
means of exposing this information. martin@ had asked for non-x86
support in PR pkg/53975, one of the barriers being I imagine few people
have the hardware to test with. I don't.)

Dave




Re: CVS commit: src

2020-10-27 Thread nia
On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> this doesn't seem like the right design.  we have cpus
> already that have multiple frequency domains, so this
> doesn't work with that setup, so attempt to use it as a
> general method for estd etc seems limited and thsu not
> the right method.
> 
> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> 4 slow and 2 fast cores it has, and they have both
> separate controls as well as list of available freqs:
> 
> machdep.cpufreq.cpu0.target = 1416
> machdep.cpufreq.cpu0.current = 1416
> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> machdep.cpufreq.cpu4.target = 1800
> machdep.cpufreq.cpu4.current = 1800
> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
>

yeah, i'm aware of this, my intent was really only to normalize
the variables that didn't have multi-cpu-domain support (since
those are already normalized as rk3399)

do you think we should use the same variable and tie things to
under cpu0 when there isn't support for scaling independent CPUs?

> additionally, if we are going to design a "good" API for
> this, it should publish things outside of "machdep".
> i'd go with hw.cpufreq probbaly.
> 
> (i didn't look, but it sure would be annoying if the old
> nodes that have existed for over a decade were changed
> and any other 3rd party code or scrip tis now broken.)

i actually picked this name because it was already in use and
thus already checked by estd.

i agree it should go outside machdep, but i didn't want
to break existing code.


Re: CVS commit: src/usr.bin/make

2020-10-26 Thread David Holland
On Sun, Oct 25, 2020 at 05:37:36PM +, Simon J. Gerraty wrote:
 > Modified Files:
 >  src/usr.bin/make: main.c
 >  src/usr.bin/make/unit-tests: varmod-match-escape.exp
 > 
 > Log Message:
 > Skip reading .MAKE.DEPENDFILE if set to
 > "/dev/null" or anything starting with "no".
 > 
 > Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223564

I object to this, particularly the "no" part but also making /dev/null
magic.

This is an unnecessary workaround for a bug in freebsd's build
system.

If there's going to be a change, it should be removing the :T from the
generated reference; there is no reason to remove the directory name
from a user-supplied .MAKE.DEPENDFILE, and the default doesn't have a
directory part. That would also remove the problem freebsd's seeing,
and would be, y'know, actually correct.

(also the application of :T is undocumented as well as wrong)


kept for reference:

 > To generate a diff of this commit:
 > cvs rdiff -u -r1.388 -r1.389 src/usr.bin/make/main.c
 > cvs rdiff -u -r1.1 -r1.2 src/usr.bin/make/unit-tests/varmod-match-escape.exp

-- 
David A. Holland
dholl...@netbsd.org


re: CVS commit: src

2020-10-26 Thread matthew green
"Nia Alarie" writes:
> Module Name:  src
> Committed By: nia
> Date: Sun Oct 25 16:39:00 UTC 2020
>
> Modified Files:
>   src/share/man/man4: acpicpu.4
>   src/share/man/man4/man4.x86: est.4 powernow.4
>   src/sys/arch/evbmips/loongson: loongson_clock.c
>   src/sys/arch/macppc/dev: obio.c
>   src/sys/arch/x86/acpi: acpi_cpu_md.c
>   src/sys/arch/x86/x86: est.c powernow.c
>
> Log Message:
> Normalize some machine dependent CPU frequenct sysctl variables.
>
> This moves machdep.*.frequency.* to machdep.cpu.frequency.*.
>
> This was proposed on tech-kern some time ago. The intention is to allow
> third-party tools such as estd and conky to more easily and reliably
> fetch or modify the current CPU frequency without iterating through
> various machine-dependent variables to check their presence.

sorry, i must have missed your tech-kern post.

this doesn't seem like the right design.  we have cpus
already that have multiple frequency domains, so this
doesn't work with that setup, so attempt to use it as a
general method for estd etc seems limited and thsu not
the right method.

eg, rk3399 systems have .cpu0 and .cpu4 domains for the
4 slow and 2 fast cores it has, and they have both
separate controls as well as list of available freqs:

machdep.cpufreq.cpu0.target = 1416
machdep.cpufreq.cpu0.current = 1416
machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
machdep.cpufreq.cpu4.target = 1800
machdep.cpufreq.cpu4.current = 1800
machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408


additionally, if we are going to design a "good" API for
this, it should publish things outside of "machdep".
i'd go with hw.cpufreq probbaly.


.mrg.

(i didn't look, but it sure would be annoying if the old
nodes that have existed for over a decade were changed
and any other 3rd party code or scrip tis now broken.)


Re: CVS commit: src/sbin/mount

2020-10-25 Thread nia
On Sat, Oct 24, 2020 at 10:38:04PM +0700, Robert Elz wrote:
>   | file systems that are used as what spools?
> 
> Ah, youth!
> 
> The old text:
>   This option is useful for optimizing read performance on file systems
>   that are used as news spools.
> was refering to netnews (usenet, NNTP or whatever).

Don't worry, I know about usenet. I just think it's a particularly
obscure use case today, even for netbsd!

> Such a filesystem is almost certainly not going to care about access times
> (this is about uses for the noatime flag, to save others needing to go look
> at what changed) as the news articles are referenced by large numbers of
> news readers, and outgoing feeds, and when any of that happened is of no
> interest to the server or its maintainers, at all - but it happens (or
> happened, when usenet was a big thing) a lot, and not bothering to update
> the access times could mean a lot of unnecessary writes to an already very
> busy filesystem.
> 
> All that said, note that I am not objecting to the change (referring to
> flash based filesystems rather than news spools) it is a little more
> currently relevant.
> 
> kre

Thanks for the background information.


Re: CVS commit: src/sbin/mount

2020-10-24 Thread David Holland
On Sat, Oct 24, 2020 at 10:51:34AM +, Nia Alarie wrote:
 > Modified Files:
 >  src/sbin/mount: mount.8
 > 
 > Log Message:
 > file systems that are used as what spools?

Kibozing caches.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Julian Coleman
Hi Tobias,

> If you're interested there is an older version[1] of envctrl in the
> Attic that might be relevant to use for reference. It supported fan
> speed controls on E450. IIRC I got some of the magic constants from
> OpenSolaris. Sadly I don't own an E450 any more.
> 
> [1] 
> cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN

Thank you - that's useful information!

Related to the magic offsets, I noticed that the value read from the sensor
was always lower than the value written.  However, it doesn't appear to be
a constant difference (I see about 15 for most values, but only 5 for the
minimum).  I think that it's OK to keep the higher value - it'll mean that
we run the fans slightly faster.  The CPU temperature on my E250 doesn't
reach the minimum threshold where the fan speed actually increases, so I
don't think that this will have any impact.

The GPIO values there helps to see what values I should be checking for too.

It would be good to merge this with the current code, but I only have an
E250 to test on, so I'll need to find a volunteer.

Regards,

Julian


Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Tobias Nygren
On Sat, 24 Oct 2020 15:16:39 +
Julian Coleman  wrote:

> Module Name:  src
> Committed By: jdc
> Date: Sat Oct 24 15:16:39 UTC 2020
> 
> Modified Files:
>   src/sys/arch/sparc64/dev: pcf8591_envctrl.c
> 
> Log Message:
> Add support for automatically changing the CPU fan speed on the E250 in a
> similar way to the SB1000/SB2000.
> The fan control information was determined by experiment, as it's only
> partially available in OFW.
> Hardcode the missing information for E250 fan control into the driver
> (it should be possible to support the E450 in future too).

If you're interested there is an older version[1] of envctrl in the
Attic that might be relevant to use for reference. It supported fan
speed controls on E450. IIRC I got some of the magic constants from
OpenSolaris. Sadly I don't own an E450 any more.

[1] 
cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN


Re: CVS commit: src/sbin/mount

2020-10-24 Thread Robert Elz
Date:Sat, 24 Oct 2020 10:51:34 +
From:"Nia Alarie" 
Message-ID:  <20201024105134.6539bf...@cvs.netbsd.org>

  | file systems that are used as what spools?

Ah, youth!

The old text:
This option is useful for optimizing read performance on file systems
that are used as news spools.
was refering to netnews (usenet, NNTP or whatever).

Such a filesystem is almost certainly not going to care about access times
(this is about uses for the noatime flag, to save others needing to go look
at what changed) as the news articles are referenced by large numbers of
news readers, and outgoing feeds, and when any of that happened is of no
interest to the server or its maintainers, at all - but it happens (or
happened, when usenet was a big thing) a lot, and not bothering to update
the access times could mean a lot of unnecessary writes to an already very
busy filesystem.

All that said, note that I am not objecting to the change (referring to
flash based filesystems rather than news spools) it is a little more
currently relevant.

kre



Re: CVS commit: src/sys/dev/wsfb

2020-10-21 Thread Rin Okuyama

Hi,

On 2020/10/21 15:42, Michael wrote:

Hello,

On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama"  wrote:


Module Name:src
Committed By:   rin
Date:   Sun Oct 18 11:54:21 UTC 2020

Modified Files:
src/sys/dev/wsfb: genfb.c

Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
when shadow FB is used.


This flag is a hint for X, telling it that the memory used as
framebuffer is regular RAM ( where using a shadowfb in X would be a
waste of time and RAM ), not for example PCI RAM ( where a shadowfb
would be faster ).
In other words, it's supposed to tell X not to shadow the framebuffer.
This is why it's not set by genfb itself, which doesn't have such
knowledge about the hardware, but by drivers which do.
Shadow fb use in wsdisplay is completely private and mapping the
framebuffer through genfb will always give you whatever genfb thinks is
the actual device framebuffer.


Thank you for detailed explanation!

I already reverted this commit as jmcneill@ advised me:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/wsfb/genfb.c#rev1.77

Thanks,
rin


Re: CVS commit: src/sys/dev/wsfb

2020-10-21 Thread Michael
Hello,

On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama"  wrote:

> Module Name:  src
> Committed By: rin
> Date: Sun Oct 18 11:54:21 UTC 2020
> 
> Modified Files:
>   src/sys/dev/wsfb: genfb.c
> 
> Log Message:
> For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
> when shadow FB is used.

This flag is a hint for X, telling it that the memory used as
framebuffer is regular RAM ( where using a shadowfb in X would be a
waste of time and RAM ), not for example PCI RAM ( where a shadowfb
would be faster ).
In other words, it's supposed to tell X not to shadow the framebuffer.
This is why it's not set by genfb itself, which doesn't have such
knowledge about the hardware, but by drivers which do.
Shadow fb use in wsdisplay is completely private and mapping the
framebuffer through genfb will always give you whatever genfb thinks is
the actual device framebuffer.

have fun
Michael


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-20 Thread Joerg Sonnenberger
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote:
> I'm also one who feels hesitate to import Linux'ism into our basic
> components. However, for this problem in particular, I still think
> it is not a good choice to keep NetBSD support in driver-aarch64.c:
> 
> (a) Our sysctl(3)-based interface is not compliant to any standards,
> just like Linux's /proc/cpuinfo. But the latter is, unfortunately
> for us, the de facto standard.

It works properly in a chroot etc without needing new files. I would
call that a big plus.

Joerg


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-20 Thread Rin Okuyama

Hi,
(tech-toolchain@ added to cc)

On 2020/10/16 1:49, Kamil Rytarowski wrote:

On 15.10.2020 17:14, Rin Okuyama wrote:

On 2020/10/15 16:12, matthew green wrote:

Martin Husemann writes:

On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:

you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.  ryo@ recently
added additional /proc/cpuinfo support that should make this
just work with the upstream version, but i haven't had chance
to update and see if this is the case.


I've confirmed that -mtune=native works fine at least for A53,
even if all the local changes to driver-aarch64.c is reverted.
I will commit it soon.


If we go this route, we should make the relevant procfs nodes
independent
of -o linux.


that would be fine by me.


Nowadays, -o linux is turned on by default (unless nolinux is
specified explicitly). Still, native apps probably should not
depend on it.

This needs MI changes to procfs, not MD to aarch64. Should we
enable /proc/cpuinfo unconditionally?



I'm against the policy of restoring the /proc dependency for this corner
case in one application.

We need to upstream the NetBSD specific patches to mainline GCC.


I'm also one who feels hesitate to import Linux'ism into our basic
components. However, for this problem in particular, I still think
it is not a good choice to keep NetBSD support in driver-aarch64.c:

(a) Our sysctl(3)-based interface is not compliant to any standards,
just like Linux's /proc/cpuinfo. But the latter is, unfortunately
for us, the de facto standard.

(b) Because of (a), driver-aarch64.c is deeply depended on
/proc/cpuinfo. Our NetBSD support code

see diff to vendor branch here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/config/aarch64/driver-aarch64.c.diff?r1=1.1.1.7=1.10=h

is something like a "glue code" which converts our convention to
/proc/cpuinfo style. We already do this in procfs. Why twice?

(c) I imagine that there would be little benefits for upstream to
merge NetBSD support into their repository. If they will merge,
I don't think the code is kept updated.

(d) Only -march=native and -mtune=native depends on this feature. I'm
OK with /proc/cpuinfo is left as is; only enabled when -onolinux is
not specified. IMO, it is users' responsibility that such a
additional feature fails with their non-standard system settings.

In short, I'm worried about future when mrg@ or someone else have to
maintain our glue code eternally, if this code is not reverted.

Thanks,
rin


Re: CVS commit: src/sys

2020-10-20 Thread Paul Goyette

This still isn't quite correct.

For i386, a custom kernel build fails.  Here's the diff between GENERIC
and the custom config (this mirrors the config I used on amd64 to file
the original PR kern/55731):

--- GENERIC 2020-09-27 22:28:13.468056102 -0700
+++ TEST2020-10-20 07:41:41.302325022 -0700
@@ -22,6 +22,17 @@

 optionsINCLUDE_CONFIG_FILE # embed config file in kernel binary

+# Remove standard options, as they are provided by modules
+
+no options EXEC_SCRIPT
+no options EXEC_ELF32
+no options COREDUMP
+no options AIO
+no options MQUEUE
+no options SEMAPHORE
+no options PTRACE
+
+
 #ident "GENERIC-$Revision: 1.1233 $"

 maxusers   64  # estimated number of users
@@ -120,7 +131,7 @@
 # Diagnostic/debugging support options
 optionsDIAGNOSTIC  # inexpensive kernel consistency checks
# XXX to be commented out on release branch
-#options   DEBUG   # expensive debugging checks/support
+optionsDEBUG   # expensive debugging checks/support
 #options   LOCKDEBUG   # expensive locking checks/support
 optionsDDB # in-kernel debugger
 #options   DDB_ONPANIC=1   # see also sysctl(7): `ddb.onpanic'


Here's the build failure (with sources updated Tue Oct 20 14:02:24 UTC)

...
#  link  TEST/netbsd
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld -Map netbsd.map 
--cref -T netbsd.ldscript -Ttext c010 -e start -X -o netbsd 
${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: 
process_machdep.o: in function `ptrace_machdep_dorequest':
/build/netbsd-compat/src/sys/arch/i386/i386/process_machdep.c:298: undefined 
reference to `ptrace_update_lwp'
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: 
/build/netbsd-compat/src/sys/arch/i386/i386/process_machdep.c:324: undefined 
reference to `ptrace_update_lwp'
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: procfs_fpregs.o: 
in function `procfs_dofpregs':
/build/netbsd-compat/src/sys/miscfs/procfs/procfs_fpregs.c:96: undefined 
reference to `process_dofpregs'
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: procfs_fpregs.o: 
in function `procfs_validfpregs':
/build/netbsd-compat/src/sys/miscfs/procfs/procfs_fpregs.c:103: undefined 
reference to `process_validfpregs'
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: procfs_regs.o: 
in function `procfs_doregs':
/build/netbsd-compat/src/sys/miscfs/procfs/procfs_regs.c:93: undefined 
reference to `process_doregs'
/build/netbsd-compat/tools/x86_64/i386/bin/i486--netbsdelf-ld: procfs_regs.o: 
in function `procfs_validregs':
/build/netbsd-compat/src/sys/miscfs/procfs/procfs_regs.c:100: undefined 
reference to `process_validregs'
*** [netbsd] Error code 1

nbmake: stopped in /build/netbsd-compat/obj/i386/sys/arch/i386/compile/TEST
1 error



On Mon, 19 Oct 2020, Christos Zoulas wrote:


Module Name:src
Committed By:   christos
Date:   Mon Oct 19 19:33:02 UTC 2020

Modified Files:
src/sys/arch/amd64/conf: MODULAR files.amd64
src/sys/kern: compat_stub.c core_elf32.c files.kern kern_core.c
kern_sig.c
src/sys/modules/coredump: Makefile
src/sys/modules/exec_elf32: Makefile
src/sys/modules/exec_elf64: Makefile
src/sys/modules/ptrace_common: Makefile
src/sys/sys: compat_stub.h exec_elf.h
Added Files:
src/sys/modules/ptrace_common: machdep.mk

Log Message:
Arrange so that no options COREDUMP and no options PTRACE work together.
Thanks to Paul Goyette for testing.


To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/sys/arch/amd64/conf/MODULAR
cvs rdiff -u -r1.117 -r1.118 src/sys/arch/amd64/conf/files.amd64
cvs rdiff -u -r1.19 -r1.20 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.65 -r1.66 src/sys/kern/core_elf32.c
cvs rdiff -u -r1.52 -r1.53 src/sys/kern/files.kern
cvs rdiff -u -r1.30 -r1.31 src/sys/kern/kern_core.c
cvs rdiff -u -r1.390 -r1.391 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.6 -r1.7 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.5 -r1.6 src/sys/modules/exec_elf32/Makefile
cvs rdiff -u -r1.4 -r1.5 src/sys/modules/exec_elf64/Makefile
cvs rdiff -u -r1.3 -r1.4 src/sys/modules/ptrace_common/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/ptrace_common/machdep.mk
cvs rdiff -u -r1.23 -r1.24 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.167 -r1.168 src/sys/sys/exec_elf.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


!DSPAM:5f8dea32273387311682910!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |

Re: CVS commit: src/sys

2020-10-20 Thread Paul Goyette

I am getting errors, too, when I build a NOCOMPAT kernel:

#  link  NOCOMPAT/netbsd
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map 
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -z 
max-page-size=0x20 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} 
${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: kern_core.o: in 
function `coredump_modcmd':
/build/netbsd-compat/src_ro/sys/kern/kern_core.c:91: undefined reference to 
`real_coredump_elf32'
*** [netbsd] Error code 1


On Tue, 20 Oct 2020, Rin Okuyama wrote:


Hi,

This causes build failures for LP64 archs without COMPAT_NETBSD32,
i.e., alpha and ie64:

kern_core.o: in function `coredump_modcmd':
(.text+0x1c4): undefined reference to `real_coredump_elf32

https://releng.netbsd.org/builds/HEAD/202010200300Z/

(Failure for aarch64eb is irrelevant, and already fixed by ryo.)

Protect the code with COMPAT_NETBSD32 or EXEC_ELF32?

Thanks,
rin

On 2020/10/20 4:33, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Mon Oct 19 19:33:02 UTC 2020

Modified Files:
src/sys/arch/amd64/conf: MODULAR files.amd64
src/sys/kern: compat_stub.c core_elf32.c files.kern kern_core.c
kern_sig.c
src/sys/modules/coredump: Makefile
src/sys/modules/exec_elf32: Makefile
src/sys/modules/exec_elf64: Makefile
src/sys/modules/ptrace_common: Makefile
src/sys/sys: compat_stub.h exec_elf.h
Added Files:
src/sys/modules/ptrace_common: machdep.mk

Log Message:
Arrange so that no options COREDUMP and no options PTRACE work together.
Thanks to Paul Goyette for testing.


To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/sys/arch/amd64/conf/MODULAR
cvs rdiff -u -r1.117 -r1.118 src/sys/arch/amd64/conf/files.amd64
cvs rdiff -u -r1.19 -r1.20 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.65 -r1.66 src/sys/kern/core_elf32.c
cvs rdiff -u -r1.52 -r1.53 src/sys/kern/files.kern
cvs rdiff -u -r1.30 -r1.31 src/sys/kern/kern_core.c
cvs rdiff -u -r1.390 -r1.391 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.6 -r1.7 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.5 -r1.6 src/sys/modules/exec_elf32/Makefile
cvs rdiff -u -r1.4 -r1.5 src/sys/modules/exec_elf64/Makefile
cvs rdiff -u -r1.3 -r1.4 src/sys/modules/ptrace_common/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/ptrace_common/machdep.mk
cvs rdiff -u -r1.23 -r1.24 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.167 -r1.168 src/sys/sys/exec_elf.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


!DSPAM:5f8ed8b3121927188711769!



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-10-20 Thread Rin Okuyama

Hi,

This causes build failures for LP64 archs without COMPAT_NETBSD32,
i.e., alpha and ie64:

kern_core.o: in function `coredump_modcmd':
(.text+0x1c4): undefined reference to `real_coredump_elf32

https://releng.netbsd.org/builds/HEAD/202010200300Z/

(Failure for aarch64eb is irrelevant, and already fixed by ryo.)

Protect the code with COMPAT_NETBSD32 or EXEC_ELF32?

Thanks,
rin

On 2020/10/20 4:33, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Mon Oct 19 19:33:02 UTC 2020

Modified Files:
src/sys/arch/amd64/conf: MODULAR files.amd64
src/sys/kern: compat_stub.c core_elf32.c files.kern kern_core.c
kern_sig.c
src/sys/modules/coredump: Makefile
src/sys/modules/exec_elf32: Makefile
src/sys/modules/exec_elf64: Makefile
src/sys/modules/ptrace_common: Makefile
src/sys/sys: compat_stub.h exec_elf.h
Added Files:
src/sys/modules/ptrace_common: machdep.mk

Log Message:
Arrange so that no options COREDUMP and no options PTRACE work together.
Thanks to Paul Goyette for testing.


To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/sys/arch/amd64/conf/MODULAR
cvs rdiff -u -r1.117 -r1.118 src/sys/arch/amd64/conf/files.amd64
cvs rdiff -u -r1.19 -r1.20 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.65 -r1.66 src/sys/kern/core_elf32.c
cvs rdiff -u -r1.52 -r1.53 src/sys/kern/files.kern
cvs rdiff -u -r1.30 -r1.31 src/sys/kern/kern_core.c
cvs rdiff -u -r1.390 -r1.391 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.6 -r1.7 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.5 -r1.6 src/sys/modules/exec_elf32/Makefile
cvs rdiff -u -r1.4 -r1.5 src/sys/modules/exec_elf64/Makefile
cvs rdiff -u -r1.3 -r1.4 src/sys/modules/ptrace_common/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/ptrace_common/machdep.mk
cvs rdiff -u -r1.23 -r1.24 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.167 -r1.168 src/sys/sys/exec_elf.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Re: CVS commit: src/sys/kern

2020-10-19 Thread Christos Zoulas
In article <20201019144701.a6d3bf...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Mon Oct 19 14:47:01 UTC 2020
>
>Modified Files:
>   src/sys/kern: sys_ptrace.c sys_ptrace_common.c
>
>Log Message:
>Remove obsolete references to 4.4BSD papers

This removes the ptrace module code. Please diff before committing!

christos



re: CVS commit: src/distrib/sets/lists/debug

2020-10-18 Thread matthew green
"Rin Okuyama" writes:
> Module Name:  src
> Committed By: rin
> Date: Sun Oct 18 10:10:18 UTC 2020
> 
> Modified Files:
>   src/distrib/sets/lists/debug: mi module.mi
> 
> Log Message:
> Fix build for mips; move from mi to module.mi debug symbols for
> test cases only available when MKKMOD=yes.

thanks.  i thought i'd run a full build...


.mrg.


Re: CVS commit: src/sys/dev/wsfb

2020-10-18 Thread Rin Okuyama

On 2020/10/18 21:18, Jared McNeill wrote:

I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get 
when you mmap the device. When shadow FB is used, that is generally only used 
for rasops and mmap bypasses the shadow and uses device memory directly. So I 
think this could cause performance regressions on such hardware where shadow FB 
is enabled and reading VRAM is slow.

What problem are you attempting to solve with this change?


Ah, I misunderstood its intention. I will revert this commit.
Thank you for pointing out!

PS
I came across this flag bit when I was examining byte-order problems
of framebuffer on aarch64eb. I'm just going to send a message to you.
I will soon!

Thanks,
rin


Re: CVS commit: src/sys/dev/wsfb

2020-10-18 Thread Jared McNeill
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you 
get when you mmap the device. When shadow FB is used, that is generally 
only used for rasops and mmap bypasses the shadow and uses device memory 
directly. So I think this could cause performance regressions on such 
hardware where shadow FB is enabled and reading VRAM is slow.


What problem are you attempting to solve with this change?


On Sun, 18 Oct 2020, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Sun Oct 18 11:54:21 UTC 2020

Modified Files:
src/sys/dev/wsfb: genfb.c

Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
when shadow FB is used.


To generate a diff of this commit:
cvs rdiff -u -r1.74 -r1.75 src/sys/dev/wsfb/genfb.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-16 Thread Robert Elz
Date:Fri, 16 Oct 2020 04:07:31 +
From:"Thomas Mueller" 
Message-ID:  <20201016052422.e063084...@mail.netbsd.org>

  | Should I add ,linux to the end of the procfs line?

You can, but it isn't needed these days -- I used to mount procfs twice,
once without the linux option, on /proc, and once with, on /emul/linux/proc)
but there seems to be little point in that any more (even though the linux
/proc has a whole bunch of trash that has nothing to do with processes, and
should be, and generally is, available from /kern ... /proc/cpuinfo is an
example of that, though that one is missing from kernfs and should be added
there).

I do add "hidden" to the mount option list though, there's essentially
no point in including /proc /kern /dev/pts (or anything else like those)
in default df output (which is the only thing "hidden" generally affects).

kre



Re: CVS commit: src

2020-10-16 Thread Michał Górny
On Fri, 2020-10-16 at 04:59 +, Martin Husemann wrote:
> On Thu, Oct 15, 2020 at 05:44:45PM +, Micha? G?rny wrote:
> > Module Name:src
> > Committed By:   mgorny
> > Date:   Thu Oct 15 17:44:45 UTC 2020
> > 
> > Modified Files:
> > src/distrib/sets/lists/tests: mi
> > src/etc/mtree: NetBSD.dist.tests
> > src/tests/sys: Makefile
> > Added Files:
> > src/tests/sys/x86: Makefile t_convert_xmm_s87.c
> > 
> > Log Message:
> > Add tests for process_xmm_to_s87() and process_s87_to_xmm()
> 
> This breaks all non-x86 builds, you need to consistently use the same
> conditions for the makefiles, set lists and mtree files.
> 
> Probably easiest way out: create the directories always (but leave empty
> on non-x86). Alternative: do not use arch specific sub dirs.
> 

Thanks for the suggestion.  I've moved the dirs to mi, and hopefully
that'll resolve it for now.

-- 
Best regards,
Michał Górny



Re: CVS commit: src/sys/dev/pci

2020-10-16 Thread SAITOH Masanobu

On 2020/10/16 14:53, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Fri Oct 16 05:53:40 UTC 2020

Modified Files:
src/sys/dev/pci: if_wm.c

Log Message:
  Fixes a problem that the attach function reported
"wm_gmii_setup_phytype: Unknown PHY model. OUI=00, model=" and
"PHY type is still unknown."


This was dmesg only problem. The SGMII read/write functions were correctly set
even though error message was printed. This problem was added in if_wm.c
rev. 1.656 which added SFP support.


Don't call wm_gmii_setup_phytype() three times if
the interface uses SGMII with internal MDIO.

  Tested with I354(Rangeley(SGMII(MDIO))) and I350(SERDES(SFP), SGMII(SFP)).


To generate a diff of this commit:
cvs rdiff -u -r1.690 -r1.691 src/sys/dev/pci/if_wm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




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


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Thomas Mueller
Excerpt from Rin Okuyama:

> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
 
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?

My NetBSD system has no /kern and no /proc, do I need to mkdir these 
directories?  I just did.

kernfs and procfs were commented out in /etc/fstab .

Do I need to revive, new /etc/fstab being as shown below, is this good now?

Should I add ,linux to the end of the procfs line?

I might want to run Linux programs.

# NetBSD /targetroot/etc/fstab
# See /usr/share/examples/fstab/ for more examples.
NAME=WD2G19  /  ffs rw,log   1 1
NAME=WD2G17  none   swapsw,dp0 0
kernfs  /kern   kernfs  rw
ptyfs   /dev/ptsptyfs   rw
procfs  /proc   procfs  rw
/dev/cd0a   /cdrom  cd9660  ro,noauto

tmpfs   /var/shmtmpfs   rw,-m1777,-sram%25

Tom


Re: CVS commit: src

2020-10-15 Thread Martin Husemann
On Thu, Oct 15, 2020 at 05:44:45PM +, Micha? G?rny wrote:
> Module Name:  src
> Committed By: mgorny
> Date: Thu Oct 15 17:44:45 UTC 2020
> 
> Modified Files:
>   src/distrib/sets/lists/tests: mi
>   src/etc/mtree: NetBSD.dist.tests
>   src/tests/sys: Makefile
> Added Files:
>   src/tests/sys/x86: Makefile t_convert_xmm_s87.c
> 
> Log Message:
> Add tests for process_xmm_to_s87() and process_s87_to_xmm()

This breaks all non-x86 builds, you need to consistently use the same
conditions for the makefiles, set lists and mtree files.

Probably easiest way out: create the directories always (but leave empty
on non-x86). Alternative: do not use arch specific sub dirs.

Martin


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Kamil Rytarowski
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
 you could try reverting most of our changes to this file and
 making sure you run with /proc mounted -o linux.  ryo@ recently
 added additional /proc/cpuinfo support that should make this
 just work with the upstream version, but i haven't had chance
 to update and see if this is the case.
> 
> I've confirmed that -mtune=native works fine at least for A53,
> even if all the local changes to driver-aarch64.c is reverted.
> I will commit it soon.
> 
>>> If we go this route, we should make the relevant procfs nodes
>>> independent
>>> of -o linux.
>>
>> that would be fine by me.
> 
> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
> 
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?


I'm against the policy of restoring the /proc dependency for this corner
case in one application.

We need to upstream the NetBSD specific patches to mainline GCC.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Rin Okuyama

On 2020/10/15 16:12, matthew green wrote:

Martin Husemann writes:

On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:

you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.  ryo@ recently
added additional /proc/cpuinfo support that should make this
just work with the upstream version, but i haven't had chance
to update and see if this is the case.


I've confirmed that -mtune=native works fine at least for A53,
even if all the local changes to driver-aarch64.c is reverted.
I will commit it soon.


If we go this route, we should make the relevant procfs nodes independent
of -o linux.


that would be fine by me.


Nowadays, -o linux is turned on by default (unless nolinux is
specified explicitly). Still, native apps probably should not
depend on it.

This needs MI changes to procfs, not MD to aarch64. Should we
enable /proc/cpuinfo unconditionally?


i had to write the netbsd version of that code twice so far.
once for gcc 8.3 and 8.4, once for gcc 8.5 and 9.3, and i'd
really rather avoid having to write another version :)


Oh... Thank you very much for your hard works!

Thanks,
rin


Re: CVS commit: src

2020-10-15 Thread Kimmo Suominen
On Wed, Oct 14, 2020 at 10:13:21PM +0100, Roy Marples wrote:
> On 14/10/2020 20:07, Kimmo Suominen wrote:
> > - not interfere with (static) IPv4 configuration
> 
> How do you expect
> ifconfig_vioif0='dhcp rtsol'
> to work?

When I added the code for the rtsol keyword, I did not imagine that
it would be used with the dhcp keyword. In other words, I would have
considered that an invalid configuration (among the many other invalid
configurations you can make and that won't be checked against).

However, it would be cool if that worked.

Is there a better way to avoid having dhcpcd break a static IPv4
configuration?  Using the rtsol keyword should neither enable DHCP for
IPv4 nor enable IPv4LL address autoconfiguration.

I've adjusted the way dhcpcd gets started by rtsol: it was not necessary
to use nodhcp6 or ipv6ra_noautoconf. It was just part of how I got the
network configuration to work again after upgrading to a current that no
longer has in-kernel RA processing. Once it worked I didn't change it
further. So now the O and M flags should no longer be ignored.

> > I also think it is very good that with this change we once again
> > have backwards compatibility for configuring static network
> > addressing.
> 
> We've never lost it.

This is where we seem to have a difference in experience. For me the
IPv4 configuration was broken.

Kind regards,
+ Kimmo


re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread matthew green
Martin Husemann writes:
> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> > you could try reverting most of our changes to this file and
> > making sure you run with /proc mounted -o linux.  ryo@ recently
> > added additional /proc/cpuinfo support that should make this
> > just work with the upstream version, but i haven't had chance
> > to update and see if this is the case.
> 
> If we go this route, we should make the relevant procfs nodes independent
> of -o linux.

that would be fine by me.

i had to write the netbsd version of that code twice so far.
once for gcc 8.3 and 8.4, once for gcc 8.5 and 9.3, and i'd
really rather avoid having to write another version :)


.mrg.


Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Martin Husemann
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> you could try reverting most of our changes to this file and
> making sure you run with /proc mounted -o linux.  ryo@ recently
> added additional /proc/cpuinfo support that should make this
> just work with the upstream version, but i haven't had chance
> to update and see if this is the case.

If we go this route, we should make the relevant procfs nodes independent
of -o linux.

Martin


re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread matthew green
"Rin Okuyama" writes:
> Module Name:  src
> Committed By: rin
> Date: Tue Oct 13 07:12:00 UTC 2020
> 
> Modified Files:
>   src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c
> 
> Log Message:
> Reduce diff with upstream a bit.
> No functional changes.

you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.  ryo@ recently
added additional /proc/cpuinfo support that should make this
just work with the upstream version, but i haven't had chance
to update and see if this is the case.

thanks!


.mrg.


Re: CVS commit: src

2020-10-14 Thread Roy Marples

On 14/10/2020 20:07, Kimmo Suominen wrote:
> - not interfere with (static) IPv4 configuration

How do you expect
ifconfig_vioif0='dhcp rtsol'
to work?

With recent dhcpcd changes, it is possible to get them working independently of 
each other, but as it stands right now, you just killed ipv4 running in vioif0.



- only update the IPv6 routing table, not the IPv6 address configuration


This is new behaviour, and this is my objection.
We've never had a knob to instruct the kernel not to apply IPv6 addresses from 
the RA.


In my view, rtsol means "Solicit a RA, apply it's configuration."
This includes starting DHCP6 based on the O or M flags inside the RA.
Your meaning of rtsol means "Solicit an RA but discard it's configuration and 
only set a default route to it."


As we have a difference of opinion, I would like to hear the opinions of others.


I also think it is very good that with this change we once again have
backwards compatibility for configuring static network addressing.


We've never lost it.
We've never really had static addressing with an RA router before either.
Looking through the NetBSD-9 sources, if the RA advertises an address you didn't 
have set, it would install one for you.
What it wouldn't do though was adjust the timings of existing addresses, which 
admitedly dhcpcd would which i suspect is the behaviour you're trying to get to.


If you want static, go full static. Anything else is probably undefined 
behaviour. This is certainly true with NetBSD-9 kernels handling RA.



My preference for a static address configuration would be to also use
defaultroute6, but since on some of my networks the routers do not
support VRRP v3, I cannot configure an IPv6 address in VRRP to be used
as the default gateway.


And now we get to the real reason.
I don't see why we should overload a generic "rtsol" command to workaround an 
issue with your network.


Would you object to adding a new command, maybe rtsol_router_only?
This is then very clear as to the behaviour desired.

Roy


Re: CVS commit: src

2020-10-14 Thread Kimmo Suominen
Hi Roy,

On Mon, Oct 12, 2020 at 03:56:44PM +0100, Roy Marples wrote:
> Can you explain how it was not functional before and how this fixes it?

I think the change was well described in the same commit in the manual
page updates that you did not quote in your message. The "rtsol" keyword
is used to enable the processing of router advertisement messages in
order to pickup the IPv6 default routes as advertised by the routers on
the network. Previously such processing was done in the kernel, but that
code has been removed. This change updates the etc/rc.d/network script
to restore the previous functionality of the "rtsol" keyword by starting
dhcpcd with the necessary options to have it do the work that previously
was done in the kernel.

The key points are to:

- not interfere with (static) IPv4 configuration
- only update the IPv6 routing table, not the IPv6 address configuration

I also think it is very good that with this change we once again have
backwards compatibility for configuring static network addressing.

For the curious, this is what I observed at boot before the change:

IPv6 mode: host
Configuring network interfaces: vioif0.
Adding interface aliases:.
route: writing to routing socket: File exists
add net default: gateway 198.51.100.129: File exists
Waiting for duplicate address detection to finish...

I was also getting repeated errors from ntpd due to DNS lookups failing
(as in my configuration they depend on IPv4 routing working).

Looking at dhcpcd processes, this is what was running:

myhost$ ps -axuww | grep dhcp 
_dhcpcd  255  0.0  0.0 22824  1396 ? I10:13PM 0:00.00 dhcpcd: [BPF 
BOOTP] vioif0 
_dhcpcd  505  0.0  0.0 22964  1972 ? I10:13PM 0:00.00 dhcpcd: 
[master] [ip4] [ip6] 
root 506  0.0  0.0 22824  1512 ? I10:13PM 0:00.00 dhcpcd: 
[privileged actioneer] 
_dhcpcd  507  0.0  0.0 22820  1364 ? I10:13PM 0:00.00 dhcpcd: 
[network proxy] 
_dhcpcd  508  0.0  0.0 22756  1316 ? I10:13PM 0:00.00 dhcpcd: 
[control proxy] 

This is how the interface was configured (dhcpcd had added IPv4 LL):

myhost$ ifconfig vioif0
vioif0: flags=0x8843 mtu 1500
ec_capabilities=0x1
ec_enabled=0
address: 82:1a:bd:99:c1:39
status: active
inet 198.51.100.134/28 broadcast 198.51.100.143 flags 0
inet 169.254.25.10/16 broadcast 169.254.255.255 flags 0
inet6 fe80::801a:bdff:fe99:c139%vioif0/64 flags 0 scopeid 0x1
inet6 2001:db8::134/64 flags 0

This is what was in the IPv4 routing table (presumably dhcpcd had added
the odd default route without a next hop address):

myhost$ netstat -rnf inet
Routing tables

Internet:
DestinationGatewayFlagsRefs  UseMtu 
Interface
defaultlink#1 UC  --  -  vioif0
198.51.100.128/28  link#1 UC  --  -  vioif0
198.51.100.134 link#1 UHl --  -  lo0
127/8  127.0.0.1  UGRS--  33624  lo0
127.0.0.1  lo0UHl --  33624  lo0
169.254/16 link#1 UC  --  -  vioif0
169.254.25.10  link#1 UHl --  -  lo0

Here is the configuration that I'm using in rc.conf and that works
without issues with my change to etc/rc.d/network:

hostname=myhost.example.com

defaultroute=198.51.100.129
ifconfig_vioif0='
inet 198.51.100.134/28
inet6 2001:db8::134/64 alias
rtsol
'

dns_search='site.example.com example.com'
dns_nameservers='10.1.1.11 10.2.1.11'
dns_options='timeout:1 attempts:5 edns0 no-tld-query'

My preference for a static address configuration would be to also use
defaultroute6, but since on some of my networks the routers do not
support VRRP v3, I cannot configure an IPv6 address in VRRP to be used
as the default gateway.

Kind regards,
+ Kimmo


Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-14 Thread Christos Zoulas
Thanks for fixing it!

christos


signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-14 Thread Kamil Rytarowski
On 13.10.2020 11:14, Leonardo Taccari wrote:
> Hello Kamil,
> 
> Kamil Rytarowski writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Oct  6 23:14:47 UTC 2020
>>
>> Modified Files:
>>  src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>>
>> Log Message:
>> Undo local patches
>>
>> They are no longer needed (and are wrong).
>> [...]
> 
> This seems to break gdb, e.g. by starting debugging sleep(1):
> 
>  | % gdb sleep
>  | Reading symbols from sleep...
>  | Reading symbols from /usr/libdata/debug//bin/sleep.debug...
>  | (gdb) r
>  | Starting program: /bin/sleep
>  | /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309: 
> internal-error: void switch_to_thread(thread_info*): Assertion `thr != NULL' 
> failed.
>  | A problem internal to GDB has been detected,
>  | further debugging may prove unreliable.
>  | Quit this debugging session? (y or n) y
>  | 
>  | This is a bug, please report it.  For instructions, see:
>  | .
>  | 
>  | /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309: 
> internal-error: void switch_to_thread(thread_info*): Assertion `thr != NULL' 
> failed.
>  | A problem internal to GDB has been detected,
>  | further debugging may prove unreliable.
>  | Create a core file of GDB? (y or n) y
>  | [ 240.7909538] sorry, pid 2675 was killed: orphaned traced process
>  | Abort (core dumped)
>  | Exit 134
>  | % gdb -core gdb.core gdb
>  | Reading symbols from gdb...
>  | Reading symbols from /usr/libdata/debug//usr/bin/gdb.debug...
>  | [New process 1687]
>  | [New process 2908]
>  | [New process 2801]
>  | [New process 1688]
>  | [New process 1668]
>  | Core was generated by `gdb'.
>  | Program terminated with signal SIGABRT, Aborted.
>  | #0  0x76efa39833ba in _lwp_kill () from /usr/lib/libc.so.12
>  | [Current thread is 1 (process 1687)]
>  | (gdb) bt
>  | #0  0x76efa39833ba in _lwp_kill () from /usr/lib/libc.so.12
>  | #1  0x76efa3983879 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
>  | #2  0xd83814e9 in dump_core () at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:204
>  | #3  0xd8386315 in internal_vproblem(internal_problem *, const char 
> *, int, const char *, typedef __va_list_tag __va_list_tag *) (
>  | problem=problem@entry=0xd8bf05e0 , 
> file=, line=, fmt=, 
> ap=ap@entry=0x7f7fff084bc8)
>  | at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:414
>  | #4  0xd83864fb in internal_verror (file=, 
> line=, fmt=, ap=ap@entry=0x7f7fff084bc8)
>  | at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:439
>  | #5  0xd862e40a in internal_error (file=file@entry=0xd8758578 
> "/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c", 
> line=line@entry=1309, fmt=)
>  | at 
> /usr/src/external/gpl3/gdb/lib/libgdbsupport/../../dist/gdbsupport/errors.cc:55
>  | #6  0xd83a96f5 in switch_to_thread (thr=0x0) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309
>  | #7  switch_to_thread (thr=) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1307
>  | #8  0xd854e02e in startup_inferior 
> (proc_target=proc_target@entry=0xd8bf1c50 , 
> pid=pid@entry=2675, ntraps=ntraps@entry=1,
>  | last_waitstatus=last_waitstatus@entry=0x0, 
> last_ptid=last_ptid@entry=0x0) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/nat/fork-inferior.c:539
>  | #9  0xd854ef07 in gdb_startup_inferior (pid=pid@entry=2675, 
> num_traps=num_traps@entry=1) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/fork-child.c:129
>  | #10 0xd84f8592 in inf_ptrace_target::create_inferior 
> (this=this@entry=0xd8bf1c50 , 
> exec_file=exec_file@entry=0x76efa67946f0 "/bin/sleep", allargs=...,
>  | env=env@entry=0x76efa6b1e400, from_tty=from_tty@entry=1) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/inf-ptrace.c:117
>  | #11 0xd82b98e0 in run_command_1 (args=, from_tty=1, 
> run_how=RUN_NORMAL) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/infcmd.c:493
>  | #12 0xd83663d2 in cmd_func (cmd=, args= out>, from_tty=) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/cli/cli-decode.c:2181
>  | #13 0xd83a402d in execute_command (p=, 
> p@entry=0x76efa6b5c020 "", from_tty=1) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/top.c:668
>  | #14 0xd82d726c in command_handler (command=0x76efa6b5c020 "") at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:588
>  | #15 0xd82d81ad in command_line_handler (rl=...) at 
> /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:773
>  | #16 0xd82d7ad5 in gdb_rl_callback_handler (rl=0x76efa6b5c200 "r") 
> at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:219
>  | #17 0xd864f85e in rl_callback_read_char () at 
> 

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Martin Husemann
On Tue, Oct 13, 2020 at 12:57:44PM +0200, Kamil Rytarowski wrote:
> > Log Message:
> > BE32 binaries are no longer supported for ARMv7 and later, and
> > therefore for aarch64eb.
> > 
> > Reject them with ENOEXEC, rather than causing illegal instruction
> > exceptions due to unexpected binary format.

> Not supported in general or on NetBSD? Big Endian 32bit is supported on
> Cavium ThunderX (at least on a selection of models if not all of them).

The new supported format is BE-8 (BE-32 is the legacy format used for big
endian arm upto v4). All newer arm either were LE only or supported BE-8 and
little endian.

Martin


Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Rin Okuyama

On 2020/10/13 19:57, Kamil Rytarowski wrote:

On 13.10.2020 09:04, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Tue Oct 13 07:04:49 UTC 2020

Modified Files:
src/sys/arch/aarch64/aarch64: exec_machdep.c

Log Message:
BE32 binaries are no longer supported for ARMv7 and later, and
therefore for aarch64eb.

Reject them with ENOEXEC, rather than causing illegal instruction
exceptions due to unexpected binary format.




Not supported in general or on NetBSD? Big Endian 32bit is supported on
Cavium ThunderX (at least on a selection of models if not all of them).



BE32 does not mean "big endian 32bit binary". It is an old binary format for
big endian 32-bit executables, that is supported up to ARMv6. ARMv7 and later
only support a new binary format, BE8.

BE8 binaries work without problem with COMPAT_NETBSD32 on aarch64eb.

Thanks,
rin


Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Kamil Rytarowski
On 13.10.2020 09:04, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Tue Oct 13 07:04:49 UTC 2020
> 
> Modified Files:
>   src/sys/arch/aarch64/aarch64: exec_machdep.c
> 
> Log Message:
> BE32 binaries are no longer supported for ARMv7 and later, and
> therefore for aarch64eb.
> 
> Reject them with ENOEXEC, rather than causing illegal instruction
> exceptions due to unexpected binary format.
> 
> 

Not supported in general or on NetBSD? Big Endian 32bit is supported on
Cavium ThunderX (at least on a selection of models if not all of them).



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-13 Thread Leonardo Taccari
Hello Kamil,

Kamil Rytarowski writes:
> Module Name:  src
> Committed By: kamil
> Date: Tue Oct  6 23:14:47 UTC 2020
>
> Modified Files:
>   src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>
> Log Message:
> Undo local patches
>
> They are no longer needed (and are wrong).
> [...]

This seems to break gdb, e.g. by starting debugging sleep(1):

 | % gdb sleep
 | Reading symbols from sleep...
 | Reading symbols from /usr/libdata/debug//bin/sleep.debug...
 | (gdb) r
 | Starting program: /bin/sleep
 | /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309: 
internal-error: void switch_to_thread(thread_info*): Assertion `thr != NULL' 
failed.
 | A problem internal to GDB has been detected,
 | further debugging may prove unreliable.
 | Quit this debugging session? (y or n) y
 | 
 | This is a bug, please report it.  For instructions, see:
 | .
 | 
 | /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309: 
internal-error: void switch_to_thread(thread_info*): Assertion `thr != NULL' 
failed.
 | A problem internal to GDB has been detected,
 | further debugging may prove unreliable.
 | Create a core file of GDB? (y or n) y
 | [ 240.7909538] sorry, pid 2675 was killed: orphaned traced process
 | Abort (core dumped)
 | Exit 134
 | % gdb -core gdb.core gdb
 | Reading symbols from gdb...
 | Reading symbols from /usr/libdata/debug//usr/bin/gdb.debug...
 | [New process 1687]
 | [New process 2908]
 | [New process 2801]
 | [New process 1688]
 | [New process 1668]
 | Core was generated by `gdb'.
 | Program terminated with signal SIGABRT, Aborted.
 | #0  0x76efa39833ba in _lwp_kill () from /usr/lib/libc.so.12
 | [Current thread is 1 (process 1687)]
 | (gdb) bt
 | #0  0x76efa39833ba in _lwp_kill () from /usr/lib/libc.so.12
 | #1  0x76efa3983879 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
 | #2  0xd83814e9 in dump_core () at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:204
 | #3  0xd8386315 in internal_vproblem(internal_problem *, const char 
*, int, const char *, typedef __va_list_tag __va_list_tag *) (
 | problem=problem@entry=0xd8bf05e0 , 
file=, line=, fmt=, 
ap=ap@entry=0x7f7fff084bc8)
 | at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:414
 | #4  0xd83864fb in internal_verror (file=, 
line=, fmt=, ap=ap@entry=0x7f7fff084bc8)
 | at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:439
 | #5  0xd862e40a in internal_error (file=file@entry=0xd8758578 
"/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c", 
line=line@entry=1309, fmt=)
 | at 
/usr/src/external/gpl3/gdb/lib/libgdbsupport/../../dist/gdbsupport/errors.cc:55
 | #6  0xd83a96f5 in switch_to_thread (thr=0x0) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309
 | #7  switch_to_thread (thr=) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1307
 | #8  0xd854e02e in startup_inferior 
(proc_target=proc_target@entry=0xd8bf1c50 , 
pid=pid@entry=2675, ntraps=ntraps@entry=1,
 | last_waitstatus=last_waitstatus@entry=0x0, 
last_ptid=last_ptid@entry=0x0) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/nat/fork-inferior.c:539
 | #9  0xd854ef07 in gdb_startup_inferior (pid=pid@entry=2675, 
num_traps=num_traps@entry=1) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/fork-child.c:129
 | #10 0xd84f8592 in inf_ptrace_target::create_inferior 
(this=this@entry=0xd8bf1c50 , 
exec_file=exec_file@entry=0x76efa67946f0 "/bin/sleep", allargs=...,
 | env=env@entry=0x76efa6b1e400, from_tty=from_tty@entry=1) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/inf-ptrace.c:117
 | #11 0xd82b98e0 in run_command_1 (args=, from_tty=1, 
run_how=RUN_NORMAL) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/infcmd.c:493
 | #12 0xd83663d2 in cmd_func (cmd=, args=, from_tty=) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/cli/cli-decode.c:2181
 | #13 0xd83a402d in execute_command (p=, 
p@entry=0x76efa6b5c020 "", from_tty=1) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/top.c:668
 | #14 0xd82d726c in command_handler (command=0x76efa6b5c020 "") at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:588
 | #15 0xd82d81ad in command_line_handler (rl=...) at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:773
 | #16 0xd82d7ad5 in gdb_rl_callback_handler (rl=0x76efa6b5c200 "r") at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:219
 | #17 0xd864f85e in rl_callback_read_char () at 
/usr/src/external/gpl3/gdb/dist/readline/readline/callback.c:281
 | #18 0xd82d6c5e in gdb_rl_callback_read_char_wrapper_noexcept () at 
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:177
 | #19 0xd82d78e0 in gdb_rl_callback_read_char_wrapper 
(client_data=) at 

Re: CVS commit: src/usr.sbin/sysinst

2020-10-12 Thread Martin Husemann
On Tue, Oct 13, 2020 at 12:15:58AM +0900, Izumi Tsutsui wrote:
> IIRC I added it to avoid users from accidentally destroy existing native
> Windows partition (for NetBSD/arc that initially required FAT partition).

I see. If needed we can add more safety checks when setting the newfs flag
(like we do in other places: silently run fsck_$fs -p) - but the way it was
now caused tricky fallout when the kernel was able to mount the new EFI
boot partition (due to a previous FAT partition starting at the same spot),
but copying the EFI bootloaders failed.

Martin


Re: CVS commit: src/usr.sbin/sysinst

2020-10-12 Thread Izumi Tsutsui
martin@ wrote:

> Module Name:  src
> Committed By: martin
> Date: Mon Oct 12 14:29:41 UTC 2020
> 
> Modified Files:
>   src/usr.sbin/sysinst: disks.c
> 
> Log Message:
> Remove very strange code that special-cased MSDOS file systems and refused
> to newfs the partition (despite explicit request to do so) if it was
> mountable.
> Accidently carried over from a dim and distant past, before we had
> fsck_newfs.

http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/distrib/utils/sysinst/Attic/disks.c#rev1.98
http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/distrib/utils/sysinst/arch/arc/Attic/md.c#rev1.29

IIRC I added it to avoid users from accidentally destroy existing native
Windows partition (for NetBSD/arc that initially required FAT partition).

---
Izumi Tsutsui


Re: CVS commit: src

2020-10-12 Thread Roy Marples

Hi Kimmo

On 11/10/2020 23:38, Kimmo Suominen wrote:

Module Name:src
Committed By:   kim
Date:   Sun Oct 11 22:38:48 UTC 2020

Modified Files:
src/etc/rc.d: network
src/share/man/man5: ifconfig.if.5

Log Message:
Make "rtsol" functional again.


rtsol)
if ! checkyesno dhcpcd; then
-   /sbin/dhcpcd -n --ipv6rs \
+   /sbin/dhcpcd -n -f /dev/null \
+   --background --persistent \
+   --noipv4 --nodhcp6 \
+   --ipv6ra_noautoconf \
${dhcpcd_flags} $int
fi
;;

Can you explain how it was not functional before and how this fixes it?

Roy


Re: CVS commit: src/sys/dev/pci

2020-10-12 Thread Michael
Hello,

On Sun, 11 Oct 2020 21:41:57 +
"Julian Coleman"  wrote:

> Module Name:  src
> Committed By: jdc
> Date: Sun Oct 11 21:41:57 UTC 2020
> 
> Modified Files:
>   src/sys/dev/pci: radeonfb.c
> 
> Log Message:
...
>   don't ignore the bottom 200 lines of the display (for no apparent reason))

The reason I have that in most of my drivers is so I can see a good
part of the glyph cache, which starts right below the VRAM area used by
wsdisplay. Most drivers use it only for anti-aliased fonts so you
probably didn't see anything there...

have fun
Michael


re: CVS commit: src/sys/kern

2020-10-08 Thread David H. Gutteridge

On Mon, 07 Sep 2020 at 20:47:25 +1000, matthew green wrote:

"Jason R Thorpe" writes:

Module Name:src
Committed By:   thorpej
Date:   Mon Sep  7 03:50:41 UTC 2020

Modified Files:
src/sys/kern: files.kern init_main.c

Log Message:
Add the ability to set an alternate cnmagic in the kernel config
file, e.g.:

optionsCNMAGIC="\"+\""


thanks!  i need this for my er4 that some how does do break properly..

options(4) update?


I just added an entry for this to options(4). The bare bones, anyway.

(It seems that DDB_BREAK_CHAR is only used in one place now, that being
src/sys/arch/arm/sa11x0/sa11x0_com.c. I'm not sure if another detail to
contextualize DDB_BREAK_CHAR vs. CNMAGIC would be warranted?)

Dave


Re: CVS commit: src/external/public-domain/tz/dist

2020-10-08 Thread Robert Elz
Date:Thu, 08 Oct 2020 19:11:59 +1100
From:matthew green 
Message-ID:  <22915.1602144...@splode.eterna.com.au>

  | at least pacificnew is referenced by the build still:

Yes, sorry, the way that tzdata updates get done makes it
essentially impossible to test what is going to happen until
after it is done (I suspect that's true for most of the
things we handle using cvs import).   One of the things that
cvs doesn't make easy.

I fixed it when my test build failed because of it, and then
Nick fixed the remaining build problem just about the same time
my restarted build found that one (thanks).

kre



re: CVS commit: src/external/public-domain/tz/dist

2020-10-08 Thread matthew green
"Robert Elz" writes:
> Module Name:  src
> Committed By: kre
> Date: Thu Oct  8 04:28:00 UTC 2020
> 
> Modified Files:
>   src/external/public-domain/tz/dist: TZDATA_VERSION
> Removed Files:
>   src/external/public-domain/tz/dist: pacificnew systemv yearistype.sh

at least pacificnew is referenced by the build still:

external/public-domain/tz/share/zoneinfo/Makefile:YDATA=  
$(PRIMARY_YDATA) pacificnew etcetera backward

can you have a look?  thanks.


.mrg.


Re: CVS commit: src/sys/arch

2020-10-06 Thread Thomas Klausner
Thank you very much!
 Thomas

> On 06.10.2020, at 15:42, Christos Zoulas  wrote:
> 
> Module Name:  src
> Committed By: christos
> Date: Tue Oct  6 13:42:03 UTC 2020
> 
> Modified Files:
>   src/sys/arch/aarch64/include: vmparam.h
>   src/sys/arch/amd64/include: vmparam.h
>   src/sys/arch/mips/include: vmparam.h
>   src/sys/arch/riscv/include: vmparam.h
>   src/sys/arch/sparc64/include: vmparam.h
> 
> Log Message:
> GC unused MAXTSIZ32
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.15 -r1.16 src/sys/arch/aarch64/include/vmparam.h
> cvs rdiff -u -r1.52 -r1.53 src/sys/arch/amd64/include/vmparam.h
> cvs rdiff -u -r1.63 -r1.64 src/sys/arch/mips/include/vmparam.h
> cvs rdiff -u -r1.5 -r1.6 src/sys/arch/riscv/include/vmparam.h
> cvs rdiff -u -r1.40 -r1.41 src/sys/arch/sparc64/include/vmparam.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 
> Modified files:
> 
> Index: src/sys/arch/aarch64/include/vmparam.h
> diff -u src/sys/arch/aarch64/include/vmparam.h:1.15 
> src/sys/arch/aarch64/include/vmparam.h:1.16
> --- src/sys/arch/aarch64/include/vmparam.h:1.15   Wed Sep 23 01:02:27 2020
> +++ src/sys/arch/aarch64/include/vmparam.hTue Oct  6 09:42:03 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: vmparam.h,v 1.15 2020/09/23 05:02:27 skrll Exp $ */
> +/* $NetBSD: vmparam.h,v 1.16 2020/10/06 13:42:03 christos Exp $ */
> 
> /*-
>  * Copyright (c) 2014 The NetBSD Foundation, Inc.
> @@ -103,10 +103,6 @@
> 
> #define USRSTACK32VM_MAXUSER_ADDRESS32
> 
> -#ifndef MAXTSIZ32
> -#define  MAXTSIZ32   (1L << 26)  /* 32bit max text size (64MB) */
> -#endif
> -
> #ifndef   MAXDSIZ32
> #define   MAXDSIZ32   (3U*1024*1024*1024) /* max data size */
> #endif
> 
> Index: src/sys/arch/amd64/include/vmparam.h
> diff -u src/sys/arch/amd64/include/vmparam.h:1.52 
> src/sys/arch/amd64/include/vmparam.h:1.53
> --- src/sys/arch/amd64/include/vmparam.h:1.52 Wed Jan 22 11:52:46 2020
> +++ src/sys/arch/amd64/include/vmparam.h  Tue Oct  6 09:42:03 2020
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: vmparam.h,v 1.52 2020/01/22 16:52:46 ad Exp $  */
> +/*   $NetBSD: vmparam.h,v 1.53 2020/10/06 13:42:03 christos Exp $*/
> 
> /*-
>  * Copyright (c) 1990 The Regents of the University of California.
> @@ -106,7 +106,6 @@
>  * 32bit memory related constants.
>  */
> 
> -#define MAXTSIZ32(256*1024*1024)
> #ifndef DFLDSIZ32
> #define   DFLDSIZ32   (256*1024*1024) /* initial data size 
> limit */
> #endif
> 
> Index: src/sys/arch/mips/include/vmparam.h
> diff -u src/sys/arch/mips/include/vmparam.h:1.63 
> src/sys/arch/mips/include/vmparam.h:1.64
> --- src/sys/arch/mips/include/vmparam.h:1.63  Sun Jul 26 04:08:41 2020
> +++ src/sys/arch/mips/include/vmparam.h   Tue Oct  6 09:42:03 2020
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: vmparam.h,v 1.63 2020/07/26 08:08:41 simonb Exp $  */
> +/*   $NetBSD: vmparam.h,v 1.64 2020/10/06 13:42:03 christos Exp $*/
> 
> /*
>  * Copyright (c) 1988 University of Utah.
> @@ -126,9 +126,6 @@
> /*
>  * Virtual memory related constants, all in bytes
>  */
> -#ifndef MAXTSIZ32
> -#define  MAXTSIZ32   MAXTSIZ /* max text size */
> -#endif
> #ifndef DFLDSIZ32
> #define   DFLDSIZ32   DFLDSIZ /* initial data size 
> limit */
> #endif
> 
> Index: src/sys/arch/riscv/include/vmparam.h
> diff -u src/sys/arch/riscv/include/vmparam.h:1.5 
> src/sys/arch/riscv/include/vmparam.h:1.6
> --- src/sys/arch/riscv/include/vmparam.h:1.5  Sat Jun  1 08:42:28 2019
> +++ src/sys/arch/riscv/include/vmparam.h  Tue Oct  6 09:42:03 2020
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: vmparam.h,v 1.5 2019/06/01 12:42:28 maxv Exp $ */
> +/*   $NetBSD: vmparam.h,v 1.6 2020/10/06 13:42:03 christos Exp $ */
> 
> /*-
>  * Copyright (c) 2014 The NetBSD Foundation, Inc.
> @@ -79,9 +79,6 @@
> /*
>  * Virtual memory related constants, all in bytes
>  */
> -#ifndef MAXTSIZ32
> -#define  MAXTSIZ32   MAXTSIZ /* max text size */
> -#endif
> #ifndef DFLDSIZ32
> #define   DFLDSIZ32   DFLDSIZ /* initial data size 
> limit */
> #endif
> 
> Index: src/sys/arch/sparc64/include/vmparam.h
> diff -u src/sys/arch/sparc64/include/vmparam.h:1.40 
> src/sys/arch/sparc64/include/vmparam.h:1.41
> --- src/sys/arch/sparc64/include/vmparam.h:1.40   Wed Jan 22 11:59:37 2020
> +++ src/sys/arch/sparc64/include/vmparam.hTue Oct  6 09:42:03 2020
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: vmparam.h,v 1.40 2020/01/22 16:59:37 ad Exp $ */
> +/*   $NetBSD: vmparam.h,v 1.41 2020/10/06 13:42:03 christos Exp $ */
> 
> /*
>  * Copyright (c) 1992, 1993
> @@ -155,9 +155,6 @@
> /*
>  * 32-bit emulation limits (same as sparc - we could go bigger)
>  */
> -#ifndef MAXTSIZ32
> -#define  MAXTSIZ32   (64*1024*1024)  /* max text size */
> -#endif
> #ifndef DFLDSIZ32
> #define   DFLDSIZ32   (64*1024*1024)  /* initial data 

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-06 Thread Rin Okuyama

It works fine now. Thank you for quick fix!!

rin

On 2020/10/06 15:28, Nick Hudson wrote:


On 06/10/2020 01:54, Rin Okuyama wrote:

Hi,

On 2020/10/01 1:35, Nick Hudson wrote:

Module Name:    src
Committed By:    skrll
Date:    Wed Sep 30 16:35:49 UTC 2020

Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S

Log Message:
Move el[01]_trap_exit into vectors.S where the callers exist


To generate a diff of this commit:
cvs rdiff -u -r1.27 -r1.28 src/sys/arch/aarch64/aarch64/cpuswitch.S
cvs rdiff -u -r1.18 -r1.19 src/sys/arch/aarch64/aarch64/vectors.S

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This commit seems to break COMPAT_NETBSD32. On RPI3, earmv7hf binaries
get SIGSEGV:


Hopefully fixed now with the commit below. Please let me know if you
have any other problems.

Sorry for the breakage.

Nick


Module Name:    src
Committed By:    skrll
Date:    Tue Oct  6 06:26:46 UTC 2020

Modified Files:
 src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S

Log Message:
move #include "opt_compat_netbsd32.h" to where it's required


To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/arch/aarch64/aarch64/cpuswitch.S
cvs rdiff -u -r1.19 -r1.20 src/sys/arch/aarch64/aarch64/vectors.S




  1   2   3   4   5   6   7   8   9   10   >