On 5/21/19 11:30 AM, Alex Bennée wrote: > > Richard Henderson <richard.hender...@linaro.org> writes: > >> On 5/21/19 5:08 AM, Alex Bennée wrote: >>>>> We probably need to zero or reset the xmm regs both in the test and when >>>>> risugen dumps it's preamble. >>>>> >>>> >>>> That gets fixed later in the series. >>> >>> So it does, but I'm still seeing the test fail when played back :-/ >> >> Um, no, I mean this test is extended in patch 9, exactly how you suggest. >> Are >> you trying to run the test as seen in patch 7 against the final >> series? > > Running against: > > commit 555748b35849ad4d354a9a3cd7f8549994b2bea4 (HEAD -> > review/i386-support-v2) > Author: Jan Bobek <jan.bo...@gmail.com> > Date: Fri May 17 18:44:50 2019 -0400 > > risu_reginfo_i386: accept named feature sets for --xfeature > > fails for me.
I get the same behavior, but it only occurs on 32bit builds of RISU. Specifically, in risu_reginfo_i386.c, lines 172--178: for (i = 0; i < nvecregs; ++i) { #ifdef __x86_64__ memcpy(&ri->vregs[i], &fp->xmm_space[i], 16); #else memcpy(&ri->vregs[i], &fp->_xmm[i * 4], 16); #endif } In the #else branch, fp->_xmm has type _libc_xmmreg[16], and _libc_xmmreg itself is a struct with a 4-element array of uint32s. On my box, this gets fixed by dropping the multiplication from the index, i.e. memcpy(&ri->vregs[i], &fp->_xmm[i], 16); I wonder why Richard wrote it like this in the first place; did fp->_xmm use to be an array of uint32s in previous versions of this API? -Jan
signature.asc
Description: OpenPGP digital signature