This is the mail archive of the
mailing list for the GDB project.
Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Dave Martin <Dave dot Martin at arm dot com>, <linux-arm-kernel at lists dot infradead dot org>
- Cc: <nd at arm dot com>, Christoffer Dall <christoffer dot dall at linaro dot org>, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Marc Zyngier <Marc dot Zyngier at arm dot com>, Alan Hayward <alan dot hayward at arm dot com>, <libc-alpha at sourceware dot org>, <gdb at sourceware dot org>, Torvald Riegel <triegel at redhat dot com>
- Date: Wed, 30 Nov 2016 11:05:41 +0000
- Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com> <email@example.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 30/11/16 10:08, Florian Weimer wrote:
> On 11/25/2016 08:38 PM, Dave Martin wrote:
>> The Scalable Vector Extension (SVE)  is an extension to AArch64 which
>> adds extra SIMD functionality and supports much larger vectors.
>> This series implements core Linux support for SVE.
>> Recipents not copied on the whole series can find the rest of the
>> patches in the linux-arm-kernel archives .
>> The first 5 patches "arm64: signal: ..." factor out the allocation and
>> placement of state information in the signal frame. The first three
>> are prerequisites for the SVE support patches.
>> Patches 04-05 implement expansion of the signal frame, and may remain
>> controversial due to ABI break issues:
>> * Discussion is needed on how userspace should detect/negotiate signal
>> frame size in order for this expansion mechanism to be workable.
> I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to
> disable really wide vector registers in case this causes problems with old binaries.
if the kernel does not increase the size and libc
does not add size checks then old binaries would
work with new libc just fine..
but that's non-conforming, posix requires the check.
if the kernel increases the size then it has to be
changed in bionic and musl as well and old binaries
> A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to
> its complexity.
>> The remaining patches implement initial SVE support for Linux, with the
>> following limitations:
>> * No KVM/virtualisation support for guests.
>> * No independent SVE vector length configuration per thread. This is
>> planned, but will follow as a separate add-on series.
> Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable
> functions/executors quite challenging.
i'd assume it's undefined to context switch to a different
thread or to resume a function on a different thread
(because the implementation can cache thread local state
on the stack: e.g. errno pointer).. of course this does
not stop ppl from doing it, but the practice is questionable.
> Can you detail your plans in this area?