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&r2=1.10&f=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