similar to: [LLVMdev] Intrinsics __readeflags and __writeeflags

I don't know enough about LLVM CodeGen to answer your questions. I'm just curious. What is the intended level of support for these intrinsics? Are they for reading ALU flags like CF, OF, etc, or for seldom changed control flags like TF and AC? Even DF is typically scratch, and could be used for an -Oz memmove lowering for example. I don't think LLVM will ever really support

This intrinsic seems very ill-defined, apparently it can be freely reordered and does _not_ act like a compiler barrier. [1] Other than source compatibility, why would one want this intrinsic? What semantics is it supposed to give? [1] < http://connect.microsoft.com/VisualStudio/feedback/details/691456/-readeflags-intrinsic-can-be-reordered-by-the-compiler > On Tue, Dec 17, 2013 at 11:00

These intrinsics are introduced for compatibility purposes. Besides MSVC GCC also supports it in its main trunk; ICC supports it on Windows and is going to support in the next version on Linux. 2013/12/18 Joerg Sonnenberger <joerg at britannica.bec.de> > On Tue, Dec 17, 2013 at 01:05:10PM -0800, David Majnemer wrote: > > This intrinsic seems very ill-defined, apparently it can be

On 18 Dec 2013, at 11:03, Alexey Volkov <avolkov.intel at gmail.com> wrote: > These intrinsics are introduced for compatibility purposes. > Besides MSVC GCC also supports it in its main trunk; ICC supports it on Windows and is going to support in the next version on Linux. There have been two questions, neither of which is really answered. The questions are: - Why does this need

On Tue, Dec 17, 2013 at 01:05:10PM -0800, David Majnemer wrote: > This intrinsic seems very ill-defined, apparently it can be freely > reordered and does _not_ act like a compiler barrier. [1] > Other than source compatibility, why would one want this intrinsic? What > semantics is it supposed to give? Even more, why can't it just be defined as inline function in some header?

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. I'm not > sure this patch to fix it ever got committed: >

On Fri, Aug 07, 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,

On Fri, Aug 07, 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,

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

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. --- #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void)

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 x86_64. This is inconvenient when the

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 to speed on where it's stuck.

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

(FreeDOS developers, I apologize for the redundant parts of this message. But I want to bring the SYSLINUX folks into the discussion, and the SourceForge mailing list archives are broken.) Background: I have a little Sourceforge project (http://unattended.sourceforge.net/) for which I use SYSLINUX to provide CD-ROM and PXE boot support for my boot disk. And it works great with MS-DOS. However,

Hi Tom and list, Still trying to set up Shorewall logging. I understand that Shorewall require syslog to get logging working, however I have metalog. Is this possible to use metalog as logging facility for Shorewall? I was reading http://www.shorewall.net/shorewall_logging.html and it describes other method ( ULOG ). I understand that I have to compile ULOG support in the kernel... where do I

Hi guys, At a loss trying to figure why if (has_eflag(X86_EFLAGS_ID)) returns false in my HVM domU. Standard function has_eflag() in cpucheck.c running in real mode. Works fine on PV dom0, but fails when guest is booting on my hybrid dom0. LMK if any ideas. I''ll keep digging in the manuals, but nothing so far. thanks, Mukesh

Good day to all, Gert Hulselmans requested a feature for MDISKCHK.COM that would function roughly like GETARGS.COM[1] by Murali Krishnan Ganapathy: DOS SET command output for MEMDISK kernel arguments passed by previous boot-loaders. He also needed to support the case for MEMDISK-in-a-MEMDISK type situations, where all MEMDISK kernel arguments could be gathered together and output as a list

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

https://bugzilla.mindrot.org/show_bug.cgi?id=2693 Bug ID: 2693 Summary: ssh: Include'ed host is not resolved by ssh Product: Portable OpenSSH Version: 7.4p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at

Hi guys! This newsgroup is much more helpfull then reading help files (is it about my lazyness?) so I have another SOLID question Don't want to spam usenet with particular fixme:**** error questions - lets put this situation in more common way: Where is a good source (link? help page? news archive?) where majority of fixme messages is listed with answers and recomendations what to do to fix