Date: Fri, 10 Mar 2017 19:44:44 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andrew Gierth <andrew@tao11.riddles.org.uk> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <20170310174444.GN16105@kib.kiev.ua> In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <8737ely05c.fsf@news-spur.riddles.org.uk> <CANCZdfpftVHaPahTOP0vxB-FR%2BKtpqY9JMJr=F2DGifD0fhKMQ@mail.gmail.com> <87wpbxw3yd.fsf@news-spur.riddles.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: > >>>>> "Warner" == Warner Losh <imp@bsdimp.com> writes: > > Warner> I've not had good luck getting it to work. (cortex-a7 is the > Warner> proper type name, btw). It kinda works, but ports are kinda > Warner> wonky. > > >> Well, I can now report that with a local fix for #217611 in place > >> and everything recompiled for cortex-a7, I'm not seeing any > >> wonkiness at all even with a lot of ports in use. > > Warner> Awesome. What's the local fix? Is it in FreeBSD yet? > > No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla > report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff > > My fix requires breaking the ABI, since the definition of mcontext_t > simply does not have enough space to store all the registers, so I'm > assuming it won't go into stable/11 (though that really needs _some_ > kind of fix, since the bug can be demonstrated with ordinary > floating-point code and no compile options). > > It needs attention from someone with more kernel/arm experience than I > have to see whether I've missed something obvious (or subtle). > > (Maybe I should have filed it under "kern" rather than "arm"?) When x86 AVX support was added, the very same problem existed: the x86 mcontext_t has no space to store AVX registers, and worse, architecture explicitely allowed for future coprocessors to extend the register file further. In other words, even if breaking ABI and adding the storage to mcontext_t for AVX once was decided, the solution would be not sustainable. Also note that extending mcontext_t is very painful, because it is embedded into ucontext_t in the middle, so the change means that whole signal-delivery ABI is broken. In other words, a lot of compat shims is needed, each time. The x86 solution was to put new coprocessor state outside of the mcontext_t and pointing to it. This allowed the grow to happens transparently, mostly controlled by kernel. The getcontextx(3) function was added to not change expectation of (rare) getcontext(3) consumers that ucontext_t is self-contained. One of the important getcontextx(3) users is libthr, and there the internal __getcontextx_size()/__fillcontextx2() interface was added. I am not sure which tier the ARMv6 architecture is. It would seems to migrate to tier1 almost, but the ABI was broken recently with switch to hardfp. If indeed tier1, then ABI breakage is considered imadmissible, and getcontextx() route is probably good enough. The issue I see is that there is no reserved unused fields in mcontext_t on ARM, so probably some trick with not using fpu save area at all for fpu registers might be needed. If applying your patch because the ABI breakage is permitted for ARM, note that besides requiring recompilation, we also loose ability to run older binaries, including jails.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170310174444.GN16105>