On Wed, Nov 08, 2017 at 11:02:15AM +0000, Alex Bennée wrote: > > Dave Martin <dave.mar...@arm.com> writes: > > > On Tue, Nov 07, 2017 at 03:05:48PM +0000, Alex Bennée wrote: > >> Hi, > >> > >> These patches apply on-top of the last clean-up series: > >> > >> Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu > >> cleanups > >> Date: Tue, 31 Oct 2017 14:54:37 +0000 > >> Message-Id: <20171031145444.13766-1-alex.ben...@linaro.org> > >> > >> This series adds support for SVE to RISU. Most of the initial patches > >> are plumbing changes to better support arch specific option flags > >> (cleaning up a TODO in the process). I also needed to ensure configure > >> actually honoured CPPFLAGS so it could be passed yet to be released > >> headers. > > > > Should there be a getauxval(AT_HWCAP) & HWCAP_SVE check in this series > > somewhere? > > > > I don't know enough about how RISU is structured to know whether/where > > this is needed. > > That would be a saner runtime check to do but it's a balance as RISU is > a fairly specialist tool which kind of assumes people know what they are > doing. > > The current check is on SVE_MAGIC in the header files which does mean a > binary compiled on an SVE headered system is now carrying about a much > larger register dump even when run without the --test-sve flag. > > Whether it makes sense to be more flexible is a call I'll leave up to > Peter.
Fair enough. If there is anywhere useful to put it, it would serve as a useful example -- but as you point out, this is not a typical piece of userspace software... Cheers ---Dave
