As per Saving the XMM register before function call, it seems that XMM6 to XMM15 need to be preserved by function calls on Windows but don't need to be preserved on Linux.
I have a native plugin, compiled by Visual Studio 2015, for use in Unity, which uses Mono. The C# code passes a delegate down to the native plugin, which receives it as a function pointer (annotated stdcall for the sake of 32-bit builds, although the problem I have is with 64-bit ones). So, this means the native code can call a function which is implemented by Mono.
When I do this, the Mono function seems to be clobbering XMM6 to XMM15. The code compiled by Visual Studio obviously wasn't expecting this, and proceeds to malfunction.
Any ideas for ways to solve this? Is it possible to annotate specific function pointers so that Microsoft knows they behave wrong? Are there intrinsics we can call to save and restore those registers explicitly around any calls that we know have this problem? Other ideas?
Edit with further discoveries:
The registers are only clobbered the first time a given C# function is called. I've traced it to the Mono AMD64 general trampoline. This commit fixes the bug, but Unity uses an old version of Mono which still has it. The bug is that XMM0 to XMM7 are saved and restored using MOVSD, which only saves the lower 64 bits and resets the upper 64 bits to 0, while XMM8 to XMM15 are not saved at all, which may matter if something were to use them.
This seems to work for simple cases:
#include <immintrin.h>
alignas(16) std::array<uint8_t, 512> regs;
_fxsave64(regs.data());
callToMonoGoesHere();
_fxrstor64(regs.data());
Extra steps must be taken if the function returns a floating-point value:
alignas(16) std::array<uint8_t, 512> before, after;
_fxsave64(before.data());
float f = callToMonoGoesHere();
_fxsave64(after.data());
memcpy(after.data() + 256, before.data() + 256, 160); //XMM6 to 15
_fxrstor64(after.data());
Related
I've been filling myself up with notes trying to successfully create my first program on Windows 7 with NASM, but with a few self imposed stipulations (until I'm ready to move forward). In creating this first program, however, I have a ton of questions.
.
The stipulations for now are that:
I'm running Window 7 SP1 - 64-bit
I do not wish to use DOSBox so Interrupts 0x21-24 are likely not applicable
I do not wish to rely on C so this is all NASM
I would really like to avoid downloading Visual Studio or associated WDK tools if I can (this depends on whether or not I NEED to interact with the Windows API and relates to Question 2 below)
I've downloaded and installed MinGW
I'm writing my code in Notepad++ and saving as *.asm
I am linking using "ld" for now, but from what I've read, most seem to recommend "GoLink" (and Alink hasn't been updated in years?). I'll probably migrate to GoLink after I've assured myself that "ld" may be too limiting
I want to know if printing is possible without the use of the Windows API or C because of the code below?
.
The only code example that has worked for me in some capacity can be found here.
nasm is not executing file in Windows 8
.
;FILE: main.asm
[section] .text
global _main
_main:
mov eax, 6
ret ; returns eax (exits)
Linked:
c:\Users\James\Desktop>nasm -fwin32 main.asm
c:\Users\James\Desktop>ld -e _main main.obj -o main.exe
c:\Users\James\Desktop>main.exe
c:\Users\James\Desktop>echo %errorlevel%
6
.
My questions (a ton):
The fact that in the code above "ret" by itself gives output, although it just returns whatever is in EAX, is there a way to use it (or another directive outside of the Windows API) to return the contents of a variable (hopefully a string variable)? I tried to use ret with DOS calls, but as noted above, that definitely doesn't work because I'm on a 64-bit system.
In case I absolutely must use the Windows API, is the only way to interact with it by using the WDK tools? Is there some other way because that last time I downloaded Visual Studio and associated WDK tools it took up a ton of memory and massively slowed down my computer. Is there another way to make programs give output or print to the screen either by using internal commands or some other method to use API calls? One thread I admittedly skimmed (amidst 40 more tabs I have open) mentions "Russinovich's Windows Internals" but not a direct answer. At current every time I use code with the extern commands "ld" tells me that the references to commands like WinMain/WinMain#16 are undefined. In the same vein is there a table I can consult containing accurate calls to the API (i.e. _ExitProcess#4 vs. ExitProcess). I found this link to what think may be the NT API but I'm not sure it applies given my stipulations, but in reality, I'm just kind of confused:
http://j00ru.vexillium.org/ntapi/
In bits of code I've encountered I've seen directives for [Bit 16], [Bit 32], and [Bit 64]. [Bit 16] is likely ignorable, but I'm confused by the [Bit 32] and [Bit 64] for the following reasons which may not even be related: Via the code above I'm using the command, "nasm -fwin32 main.asm", then I'm linking it successfully and going on to receive output. For some reason - though I have not read the full "ld" documentation yet - when I use the command "nasm -fwin64 main.asm" and link it in the same way I receive an error saying "main.obj: File not recognized: File format not recognized". I don't understand why differentiating between 32 and 64 while I'm on a native 64-bit machine causes an error although this probably is just unique to ld.
.
In the meantime I'll be reading this question and will post an update it if helps: Executable isn't compatible with 64 bits processor
I can't answer some parts in great detail, so I expect somebody either putting up better answer, or feel free to edit this one.
you are linking against default clib, so your _main is called after Clib is initialized, the ret with value in eax is like return 6; in C++. Then Clib correctly destructs everything and calls windows exit process with exit code 6. You can return only int from _main, and I'm not even sure if full int is propagated to exit process call, or only 8 bit value is used. So you can return single char in ASCII encoding, if you treat that number as char.
You must call Windows API, if you want to display something in console/window, or write something into file, ie. do any output (and of course also for input). There's no peripheral available to win32/64 executable directly, like in DOS CGA/EGA/VGA text modes accessible trough int 10h or video ram at B800:0000. Any try to access some I/O peripheral directly should result into access violation. Only Win API should be legal for user-level application code.
How much of WDK you need I have no idea, haven't developed anything for windows for years. I think it's even possible to create executable without WDK, which would provide correct externs and dependencies on kernel32.dll and similar, but the amount of effort is way beyond simply using proper parts of WDK or clib from MinGW.
I think your linker is set to default to 32b executable, you have to figure out what kind of object format is produced by nasm for -fwin64 and how link that one with ld.
Why the difference. The 64b OS can run 32b binaries. But you can't mix 32/64 in single executable so easily (if at all). So you are either producing 32b or 64b binary, and you have to adjust everything to it (asm instructions used, directives and options, and WinAPI calls).
A very strange, presumably meant to be helpfull behaviour of Visual Studio 2012.
When I enter a double in vb.net like:
Dim myD as Double = 1.4
When I hit enter of move my focus another way, the formatting kicks in and changes the above to:
Dim myD as Double = 1.39999999999999998
or 1.6 as
Dim myD as Double = 1.6000000000000001
This behaviour does not appear to happen for all doubles. 1.3, 1.5, 1.7 and 1.8
See this youtube movie for the behaviour in action:
http://youtu.be/afw4jg58-aU
Why, and more important, how can I prevent this?
Edit:
Extensions installed are:
Second Edit
The behaviour seems to have gone away. I do not know what has caused this so for future reference this is useless to anyone, but for now, I'm happy that I don't have to go troubleshooting as suggested.
The exact same issue is also reported in this question. Which applied to VS2010, otherwise without a usable answer.
This is an environmental problem, code is getting loaded into Visual Studio that messes with the FPU control word on your machine. It is a processor register that determines how floating point operations work, it looks like this:
The Rounding Control bits are a good source of trouble like this, they determine how the internal 80-bits precision floating point value is truncated to 64-bits. Options are round-up, round-down and round-to-nearest. The Precision Control bits are also a good candidate, options are full 64-bit precision, 53 and 24 bits.
Both VS2012 and the .NET Framework rely on the operating system default, with the expectation that this will not change afterwards. Pretty hard to diagnose trouble arises when code actually does change it, your observation strongly fits the pattern. The most common troublemakers are:
code that uses DirectX without the D3DCREATE_FPU_PRESERVE option. DirectX reprograms the precision and rounding control bits to squeeze out a bit more perf.
code that was written in an older Borland language product. Its runtime library initializes the FPU control word in a non-standard way. Otherwise a generic problem with software that relies on old runtime library or an old legacy initialization that was carried through in later releases.
in general, any code that uses a media codec or media api. Such code tends to reprogram the FPU to squeeze out perf for the same reasons that DirectX does. Especially notorious in a product I worked on which uses such codecs heavily. The codebase was peppered with calls that reset the FPU control word after making a call into external code.
Finding and eliminating such code can be very difficult. DLLs get injected into another process by a large variety of well-intended malware. The SysInternals' Autoruns utility can be very useful, it shows all the possible ways code can be injected with an easy way to disable it. Be prepared to be shocked at what you see and readily disable stuff that doesn't carry a Microsoft copyright.
For dynamic injection, you'll need a debugger to see what is loaded into VS. Start VS again and use Tools + Attach to Process to attach to the first one, selecting the unmanaged debugger. Debug + Windows + Modules shows you what DLLs are loaded. Do beware that the DLL can be transient, a shell dialog like File + Open + File will dynamically load shell extensions into VS and unload them again afterwards. Good luck with it, you'll need it and sometimes the only fix is a rather drastic one.
I had the exact same issue with Visual Studio 2012.
The "solution" if it happens to you is:
write your number in your code
let VS screw it up, e.g. when you move to another line
CTRL-Z to revert VS mess
continue writing your code
I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.
On compiling a visual basic assembly, int32 variables are cast as int64 for calls to adodb methods that require int32. This results in a method not found exceptions at run time. The unnecessary cast operation can be seen when using reflector to inspect the site of the method call and is not present in the source code.
To further muddy the waters when the code is compiled on my 64bit windows 7 machine all is well, but on a 64bit windows 2008 r2 the unnecessary cast is added.
Does any one know how to stop this happening?
Try compiling the app specifically for x86/32bit.
How do I force MSBuild to compile for 32-bit mode?
I'm writing a 64-bit Cocoa application. I need to register for global key events. So I wrote this piece of code :
- (void)awakeFromNib
{
EventHotKeyRef gMyHotKeyRef;
EventHotKeyID gMyHotKeyID;
EventTypeSpec eventType;
eventType.eventClass=kEventClassKeyboard;
eventType.eventKind=kEventHotKeyPressed;
eventType.eventClass=kEventClassKeyboard;
eventType.eventKind=kEventHotKeyPressed;
InstallApplicationEventHandler(&MyHotKeyHandler,1,&eventType,NULL,NULL);
gMyHotKeyID.signature='htk1';
gMyHotKeyID.id=1;
RegisterEventHotKey(49, cmdKey+optionKey, gMyHotKeyID,
**GetApplicationEventTarget**(), 0, &gMyHotKeyRef);
}
But since GetApplicationEventTarget() is not supported for 64-bit applications I'm getting errors. If I declare it, then I don't get any errors but the application crashes.
Is there any equivalent method for GetApplicationEventTarget() (defined in Carbon framework) to use in 64-bit applications.
Or is there any way to get the global key events using cocoa calls?
Any help is appreciated.
Thanks,
Dheeraj.
I wrote a Cocoa wrapper for Carbon hot keys (and as far as my testing showed, it works in 64-bit apps), and you can find it on github here: http://github.com/davedelong/DDHotKey
I'm using GetEventDispatcherTarget() for hotkey registration.
I think it is a documentation error when it says that GetApplicationEventTarget is not supported in 64 bits. If you look in CarbonEvents.h (from the 10.6 SDK), you see that the declaration of GetUserFocusEventTarget is bracketed by #if !__LP64__ ... #endif, but just above it, the declaration of GetApplicationEventTarget is not. GetApplicationEventTarget is probably not the cause of the crash. In your code, gMyHotKeyRef and gMyHotKeyID look like they were intended to be global variables, but they're local.
Carbon isn't supported in 64-bit applications. See the answer to this question for information on how to use CGEventTap to do this in a supported way in Cocoa.