On Mon, May 13, 2019 at 3:10 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote: > > >>> tedheadster <tedheadster@xxxxxxxxx> schrieb am 11.05.2019 um 19:19 in Nachricht > <CAP8WD_Y69T_2gk4+gUan4vKozAYtv_djF7cJ=UuiO8j54D6APw@xxxxxxxxxxxxxx>: > > On Sat, May 11, 2019 at 12:30 PM Florian Weimer <fw@xxxxxxxxxxxxx> wrote: > >> Can you capture register contents at the point of the crash? > >> > >> Does this reproduce in a chroot? Maybe you can trace the whole thing > >> with a debugger. Does the crash reproduce if you single-step through > >> the whole function? > > > > Florian, > > I figured out the problem, I just haven't written code to fix it. > > The documentation I can find is silent about what is returned in %ecx > > and %ebx when calling cpuid function 0x00000001 on IDT Winchip-C6 and > > Winchip2. > > > > I think %ecx should properly contain 0x00000000, but it instead puts > > the 'auls' characters from cpuid function 0x00000000 (vendor string > > 'CentaurHauls') in %ecx: > > > > %ebx = 0x746e6543 = "Cent" > > %edx = 0x48727561 = "aurH" > > %ecx = 0x736c7561 = "auls" > > > > This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit. > > > > So we have to code around the vendor and chip model in this case. > > Jeffrey Walton gave some coding examples I might consider > > (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380). > > > I didn't see the start of this thread, but is it another attempt to re-implement /proc/cpuinfo's flags? > No, I don't propose we re-implement /proc/cpuinfo's flags. We need code around the IDT Winchip2 not reporting correct information in %ecx when given a cpuid() request with parameter 0x00000001. - Matthew
