Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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/external/gpl3/gcc/dist/gcc/config/aarch64
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
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
