On Sun, May 19, 2019, 3:33 PM Olaf van der Spek wrote:
> On Sun, May 19, 2019 at 2:31 PM tedheadster wrote:
> >
> > On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek wrote:
> > >
> > > What's eax after cpuid function 0?
> >
> > After calling cpuid function 0x0, %eax returns the expected 0x1.
>
On Sun, May 19, 2019 at 2:31 PM tedheadster wrote:
>
> On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek wrote:
> >
> > What's eax after cpuid function 0?
>
> After calling cpuid function 0x0, %eax returns the expected 0x1.
>
> Here is the output of 'cpuid -r'.
>
> # cpuid -r
> CPU 0:
>0x
On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek wrote:
>
> What's eax after cpuid function 0?
After calling cpuid function 0x0, %eax returns the expected 0x1.
Here is the output of 'cpuid -r'.
# cpuid -r
CPU 0:
0x 0x00: eax=0x0001 ebx=0x746e6543 ecx=0x736c7561 edx=0x48727561
On Sat, May 11, 2019 at 7:19 PM tedheadster wrote:
>
> On Sat, May 11, 2019 at 12:30 PM Florian Weimer 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 reprodu
On Sat, May 18, 2019 at 6:57 PM Segher Boessenkool
wrote:
> Something like
>
> *__ebx = *__ecx = *__edx = 0;
> asm volatile("" : "+r"(*__eax), "+r"(*__ebx), "+r"(*__ecx), "+r"(*__edx));
> __cpuid (__leaf, *__eax, *__ebx, *__ecx, *__edx);
>
> should do the trick.
Segher,
that got closer,
On Sat, May 18, 2019 at 5:30 PM Segher Boessenkool
wrote:
> That won't help, the compiler will remove those dead stores.
>
> Add a
>
> asm("" ::: "memory");
>
> between these two lines?
>
This didn't seem to do anything:
--- cpuid.h.orig 2019-05-14 05:52:11.0 -0400
+++ cpuid.h 2019-05
On Mon, May 13, 2019 at 4:49 PM Mike Gilbert wrote:
>
> Just a guess: I wonder if that 'auls' value is left over from the
> previous CPUID result. If that's the case, a simple solution might be
> to zero-out ebx, ecx, and edx in __cpuid().
Mike,
I tried your suggestion and added this patch to g
On Sat, May 11, 2019 at 1:19 PM tedheadster wrote:
>
> On Sat, May 11, 2019 at 12:30 PM Florian Weimer 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 reprodu
On Mon, May 13, 2019 at 3:10 AM Ulrich Windl
wrote:
>
> >>> tedheadster schrieb am 11.05.2019 um 19:19 in
> >>> Nachricht
> :
> > On Sat, May 11, 2019 at 12:30 PM Florian Weimer wrote:
> >> Can you capture register contents at the point of the crash?
> >>
> >> Does this reproduce in a chroot?
On Sat, May 11, 2019 at 12:30 PM Florian Weimer 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,
* tedheadster:
> Here is the full disassembly with a few comments:
>
> (gdb) disassemble
> Dump of assembler code for function rdrand:
>0xb7e21440 <+0>: push %esi
>0xb7e21441 <+1>: push %ebx
>0xb7e21442 <+2>: call 0xb7e0af5d <__x86.get_pc_thunk.si>
>0xb7e21447 <+7
On Tue, May 7, 2019 at 10:55 AM Jeffrey Walton wrote:
>
> As far as I know the instruction is only defined for Intel, AMD and
> Hyogen cpus. See, for example,
> https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380.
>
Jeff,
I think you missed my point. The rdrand instruction is _not_
su
On Tue, May 7, 2019 at 10:27 AM Segher Boessenkool
wrote:
> But it should not execute it, it is guarded by some cpuid things.
>
> If the assembler does not like the insn, first do (in the same asm) an
> assembler pseudo-instruction to select a CPU that does have that insn,
> then the rdrand, and t
On Di, 07.05.19 08:50, tedheadster (tedheads...@gmail.com) wrote:
> GCC and systemd teams:
> I compiled systemd-241 and expressly set march=winchip-c6 (an i486
> class cpu). It generated illegal instructions (rdrand) in the code.
> Oddly, it does NOT do this when I set march=i486:
>
> Dump of as
GCC and systemd teams:
I compiled systemd-241 and expressly set march=winchip-c6 (an i486
class cpu). It generated illegal instructions (rdrand) in the code.
Oddly, it does NOT do this when I set march=i486:
Dump of assembler code for function rdrand:
0xb7e21440 <+0>: push %esi
0xb7e
15 matches
Mail list logo
