search for: pushf

Hello all, I am trying to implement intrinsics __readeflags and __writeeflags reading and writing EFLAGS register on x86. These intrinsics expand to two instructions popf and push to register for __readeflags and pushf and pop to register for __writeeflags. These instructions are not connected explicitly so I can't use patterns in .td file to match intrinsics. I tried to implement custom expansion making COPY DAG node with copy from EFLAGS to register. But this solution works only at -O0 level and failed at...

...Alexey Volkov <avolkov.intel at gmail.com>wrote: > Hello all, > > I am trying to implement intrinsics __readeflags and __writeeflags reading > and writing EFLAGS register on x86. > These intrinsics expand to two instructions popf and push to register for > __readeflags and pushf and pop to register for __writeeflags. > These instructions are not connected explicitly so I can't use patterns in > .td file to match intrinsics. > > I tried to implement custom expansion making COPY DAG node with copy from > EFLAGS to register. > But this solution works onl...

Agreed, never emit pushf/popf. Sorry I never committed the patch, the cmov issue got hairy and I never got to debugging it :-) I can get back to it if there's interest! On Wed, Jul 29, 2015 at 4:12 PM, Reid Kleckner <rnk at google.com> wrote: > I remember this bug. :) IMO, LLVM should never emit pushf / popf...

...ne. When compiling version 0.0.1k I get the following error: gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -c testcpuid.c -MT testcpuid.lo -MD -MP -MF .deps/testcpuid.TPlo -fPIC -DPIC -o .libs/testcpuid.lo /tmp/ccXxGHg6.s: Assembler messages: /tmp/ccXxGHg6.s:8: Error: suffix or operands invalid for `pushf' /tmp/ccXxGHg6.s:9: Error: suffix or operands invalid for `pushf' /tmp/ccXxGHg6.s:10: Error: suffix or operands invalid for `pop' /tmp/ccXxGHg6.s:13: Error: suffix or operands invalid for `push' /tmp/ccXxGHg6.s:14: Error: suffix or operands invalid for `popf' /tmp/ccXxGHg6.s:15:...

...o -MD -MP -MF .deps/libtheora_la-cpu.Tpo -c cpu.c -fPIC -DPIC -o .libs/libtheora_la-cpu.o cpu.c: In function 'cpu_init': cpu.c:96: warning: 'flags' is used uninitialized in this function /tmp/ccrDL6i4.s: Assembler messages: /tmp/ccrDL6i4.s:16: Error: suffix or operands invalid for `pushf' /tmp/ccrDL6i4.s:17: Error: suffix or operands invalid for `pushf' /tmp/ccrDL6i4.s:18: Error: suffix or operands invalid for `pop' /tmp/ccrDL6i4.s:21: Error: suffix or operands invalid for `push' /tmp/ccrDL6i4.s:22: Error: suffix or operands invalid for `popf' /tmp/ccrDL6i4.s:23...

...2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2, %[re]ax > .mmu_read_cr3 = { 0x0f, 0x20, 0xd8 }, // mov %cr3, %[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; pop...

...2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2, %[re]ax > .mmu_read_cr3 = { 0x0f, 0x20, 0xd8 }, // mov %cr3, %[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; pop...

Hi all, Does anyone have thoughts on extending v->arch.hvm_vcpu.single_step to support pre-MTF systems, in a way that would mimic the MTF? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. Right now, I''m enabling X86_EFLAGS_TF in vmx_intr_assist, just like where MTF is enabled if desired. It''s cleared at the start of vmx_exi...

I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not sure this patch to fix it ever got committed: http://reviews.llvm.org/D6629 On Wed, Jul 29, 2015 at 3:11 PM, Michael Hordijk <hoffbrinkle at hotmail.com> wrote: > > Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are > clobbering EFLAGS on...

On 7/29/15 18:35, JF Bastien wrote: > Agreed, never emit pushf/popf. Sorry I never committed the patch, the > cmov issue got hairy and I never got to debugging it :-) > I can get back to it if there's interest! You've definitely got some interest here. I've been looking at your patch on http://reviews.llvm.org/D6629 and I think I'm up...

Steven Hi, I'm unable to compile testcpuid.c with the __x86_64__ architecture (Athlon 64 processor). The messages are: /tmp/ccONleRV.s: Assembly messages: /tmp/ccONleRV.s: Error: suffix or operands invalid for 'pushf' " 'pop' " 'push' " 'popf' Is it safe to ignore this module? When I attempt to start asterisk, libspandsp.so.0 fails to load because 'top_bit' is undefined. Is this related to the compile problem? Thanks for your help, -- Michael Welter Intr...

...ntel at gmail.com>wrote: > >> Hello all, >> >> I am trying to implement intrinsics __readeflags and __writeeflags >> reading and writing EFLAGS register on x86. >> These intrinsics expand to two instructions popf and push to register for >> __readeflags and pushf and pop to register for __writeeflags. >> These instructions are not connected explicitly so I can't use patterns >> in .td file to match intrinsics. >> >> I tried to implement custom expansion making COPY DAG node with copy from >> EFLAGS to register. >> But...

...ile format elf64-x86-64 Disassembly of section .text: 0000000000000000 <bar>: 0: 53 push %rbx 1: e8 00 00 00 00 callq 6 <bar+0x6> 6: ff 0d 00 00 00 00 decl 0x0(%rip) # c <bar+0xc> c: 9c pushfq d: 5b pop %rbx e: e8 00 00 00 00 callq 13 <bar+0x13> 13: b8 01 00 00 00 mov $0x1,%eax 18: 53 push %rbx 19: 9d popfq 1a: 75 07 jne 23 <bar+0x23>...

...b". It seems consistent with gas's size suffixes, but I'm open to other ideas. Normal (non-xray) ISel should never produce this instruction, so we don't need any SDAG patterns for it. You should be able to look at existing rare x86 instructions that don't have SDAG nodes, like PUSHF, SAHF, CPUID, etc to see the minimal amount of tablegen you need to add. On Thu, Jul 14, 2016 at 4:06 AM, Dean Michael Berris <dberris at google.com> wrote: > Hi llvm-dev, > > In the review of the LLVM-side changes to support XRay (which is now > upstream as http://reviews.llvm....

...G_ARG1 "%eax" > +#endif > + > +#define _REG_RET "%" _ASM_AX > + > +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1 > +#define NATIVE_IDENTITY "mov " _REG_ARG1 ", " _REG_RET > +#define NATIVE_SAVE_FL "pushf; pop " _REG_RET > +#define NATIVE_RESTORE_FL "push " _REG_ARG1 "; popf" > +#define NATIVE_IRQ_DISABLE "cli" > +#define NATIVE_IRQ_ENABLE "sti" > +#define NATIVE_READ_CR2 "mov %cr2, " _REG_RET > +#define NATIVE_READ_CR3 &qu...

...ork in a virtual machine, and you can allow userspace to disable interrupts and still have a perfectly fine solution -- if you restrict the enabling and disabling of interrupts in userspace to the cli and sti instructions. But it does not work if you start using nested interrupt control, using pushf and popf. The virtual machine monitor must always leave hardware interrupts enabled, since it must service them without allowing the guest VM to interfere. As such, the actual state of the hardware interrupt flag is visible to userspace programs. CLI and STI get away with this, because they...

...ork in a virtual machine, and you can allow userspace to disable interrupts and still have a perfectly fine solution -- if you restrict the enabling and disabling of interrupts in userspace to the cli and sti instructions. But it does not work if you start using nested interrupt control, using pushf and popf. The virtual machine monitor must always leave hardware interrupts enabled, since it must service them without allowing the guest VM to interfere. As such, the actual state of the hardware interrupt flag is visible to userspace programs. CLI and STI get away with this, because they...

...sysretq" +#else +# define _REG_ARG1 "%eax" +#endif + +#define _REG_RET "%" _ASM_AX + +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1 +#define NATIVE_IDENTITY "mov " _REG_ARG1 ", " _REG_RET +#define NATIVE_SAVE_FL "pushf; pop " _REG_RET +#define NATIVE_RESTORE_FL "push " _REG_ARG1 "; popf" +#define NATIVE_IRQ_DISABLE "cli" +#define NATIVE_IRQ_ENABLE "sti" +#define NATIVE_READ_CR2 "mov %cr2, " _REG_RET +#define NATIVE_READ_CR3 "mov %cr3, " _REG_...

This is a small series getting rid of paravirt patching by switching completely to alternative patching for the same functionality. The basic idea is to add the capability to switch from indirect to direct calls via a special alternative patching option. This removes _some_ of the paravirt macro maze, but most of it needs to stay due to the need of hiding the call instructions from the compiler

This is a small series getting rid of paravirt patching by switching completely to alternative patching for the same functionality. The basic idea is to add the capability to switch from indirect to direct calls via a special alternative patching option. This removes _some_ of the paravirt macro maze, but most of it needs to stay due to the need of hiding the call instructions from the compiler