I have a service with code that runs for years.
Now using the VS-2019 16.3.7/8/9 I get a 0xC000001D (The thread tried to execute an invalid instruction.) exceptions on the first floating point arithmetic in the boot phase of the service on some machines.
Installing the same code base compiled with 16.2.4/5 works.
I have a full memory crash dump from one machine. The crash happens on a call to _dtol3.
I can see in the assembly code this situation.
0149477B 83 3D B4 AC 55 01 06 cmp dword ptr [__isa_available (0155ACB4h)],6
01494782 7C 15 jl _dtol3_default (01494799h)
01494784 C5 FA 7E C0 vmovq xmm0,xmm0
01494788 62 F1 FD 08 7A C0 vcvttpd2qq xmm0,xmm0 <---- CRASH
__isa_available has the value 6. On my machine the value is 5. One machine were we can see the crash is a XEON Silver 4110 running our software virtualized. Same exe runs on a XEON E5-2620. The same exe runs on all my client machines in my company without any problem (a mix of old and new Intel machines).
Looking at the called code, I can see that there is a simple difference and division of to double values comparing it to a value greater or equal 1.0.
COleDateTime nowClient = COleDateTime::GetCurrentTime(),
nowDB = GetCurrentTime();
COleDateTimeSpan diff = nowDB-nowClient;
if (diff.GetTotalMinutes()>=1) // <----- CRASH
...
Is there any way to influence the code creation in the VS to avoid the calls to this code? (Any shim, compatibility setting)
Is there any known change in VS-2019 that influences the floating math since VS 16.2.4, that might has influence on my problem?
This is a bug in the 16.3.x update of Visual Studio. Here is a link to the bug report.
Read it carefully, it actually happens on machines that support AVX512, not older CPUs as the initial post describes. This also contains a couple of workarounds to avoid the issue until Microsoft has a fix.
You can enable or disable the generation of 'advanced' instructions for each project in its "Properties" sheet:
Right click the project in the Solution Explorer and select "Properties" from the pop-up menu.
Select/Open the "C/C++" tab in the left-hand pane and then select the "Code Generation" item.
In the list of properties then presented in the right-hand pane, select "Not Set" for the "Enabled Enhanced Instruction Set" property (or whichever option will give you code that is compatible with your target PCs).
The compiler's use of vmovq implies that you have (at least) "Advanced Vector Extensions" enabled; also, I think (not 100% sure) that vcvttpd2qq is in the "AVX2" category.
Related
Interrupts are not working in inline-assembler of C++(i tried VC++ 10, GCC 4, Digital Mars). Is there any interrupt-equivalent windows free-to-access memory areas? How can i reach system properties and video ram?(can i?)
These i would like to know:
mov ah,06h
mov dl,35h
int 21f //would print '5' on screen but it isnt (works in only pure assembler)
and:
mov ax,1500h
mov ch,97h
int 2f //would get me info for the cache-hit number on DI:SI
Thank you
Win32 applications don't call interrupts, they call system services. There's a number of assembly for Windows tutorials on Iczelion's page.
How can one express bitwise logical operations in mainframe COBOL?
I have:
01 WRITE-CONTROL-CHAR.
03 WCC-NOP PIC X VALUE X'01'.
03 WCC-RESET PIC X VALUE X'02'.
03 WCC-PRINTER1 PIC X VALUE X'04'.
03 WCC-PRINTER2 PIC X VALUE X'08'.
03 WCC-START-PRINTER PIC X VALUE X'10'.
03 WCC-SOUND-ALARM PIC X VALUE X'20'.
03 WCC-KEYBD-RESTORE PIC X VALUE X'40'.
03 WCC-RESET-MDT PIC X VALUE X'80'.
In Micro Focus COBOL, I could do something like:
WCC-NOP B-AND WCC-RESET
but it seems there's no such operator on the mainframe (or at least not in Enterprise COBOL for z/OS).
Is there some (hopefully straightforward!) way to simulate/replicate bitwise logical operations in mainframe COBOL?
Your best bet appears to be 'CEESITST', as it appears to exist in z/OS COBOL. I found an example using that as well as the other bit manipulation programs.
http://esj.com/articles/2000/09/01/callable-service-manipulating-binary-data-at-the-bit-level.aspx
If you AND together values that don't share bits, you will always get zero, so I'm going to assume you meant OR. This makes sense since you tend to OR independent bits to construct a multi-bit value.
With that in mind, when the bit masks are independent of each other, as in a single term doesn't interact with other terms, there is no difference between:
termA OR termB
and:
termA + termB
Your terms are all independent here, being x'1', x'2' and so forth (no x'03' or x'ff') so adding them should work fine:
COMPUTE TARGET = WCC-NOP + WCC-RESET
Now that's good for setting bits starting with nothing, but not so useful for clearing them. However, you can use a similar trick for clearing:
COMPUTE TARGET = 255 - WCC-NOP - WCC-RESET
Setting or clearing them from an arbitrary starting point (regardless of their current state) is a little trickier and can't be done easily with addition and subtraction.
I am not very good in inline assembly, but planning to use it for optimization purpose in an Embedded project. As I don't know much of the information about it, I am in need of some help.
I am having Win CE 6.0, with ARM9, using MS Visual Studio 2005 (using MFC).
Basically, I want to make memory access faster, and do some bitwise operations.
It would be really helpful for me if I can get any online link, or some examples of using registers, variable names, pointers (some memory transfer and bitwise operations related stuff) etc for my particular environment.
EDIT after ctacke's answer:
It would be really helpful for me if there is any link or small examples to work out with .s files, specifically writing and exporting functions from .s, and steps involving in combining them with my MFC application. Any small example would do it.
Thank You.
Kind Regards,
Aftab
The ARM compilers that ship with Visual Studio (all versions) do not support inline ASM - only the x86 compilers support inline ASM. To use ASM for ARM (or SH or MIPS as well) you have to create a separate code file (typically a .s file), export functions from your ASM and call those.
EDIT
Here's a simple example (taken from here):
AREA asm_func, CODE, READONLY
; Export my_asm function location so that C compiler can find it and link
EXPORT my_asm
my_asm
;
; ARM Assembly language function to set LED1 bit to a value passed from C
; LED1 gets value (passed from C compiler in R0)
; LED1 is on GPIO port 1 bit 18
; See Chapter 9 in the LPC1768 User Manual
; for all of the GPIO register info and addresses
; Pinnames.h has the mbed modules pin port and bit connections
;
; Load GPIO Port 1 base address in register R1
LDR R1, =0x2009C020 ; 0x2009C020 = GPIO port 1 base address
; Move bit mask in register R2 for bit 18 only
MOV.W R2, #0x040000 ; 0x040000 = 1<<18 all "0"s with a "1" in bit 18
; value passed from C compiler code is in R0 - compare to a "0"
CMP R0, #0 ; value == 0 ?
; (If-Then-Else) on next two instructions using equal cond from the zero flag
ITE EQ
; STORE if EQ - clear led 1 port bit using GPIO FIOCLR register and mask
STREQ R2, [R1,#0x1C] ; if==0, clear LED1 bit
; STORE if NE - set led 1 port bit using GPIO FIOSET register and mask
STRNE R2, [R1,#0x18] ; if==1, set LED1 bit
; Return to C using link register (Branch indirect using LR - a return)
BX LR
END
I'm writing a gameboy emulator, and am struggling with making sure opcodes are emulated correctly. Certain operations set flag registers, and it can be hard to track whether the flag is set correctly, and where.
I want to write some sort of testing framework, but thought it'd be worth asking here for some help. Currently I see a few options:
Unit test each and every opcode with several test cases. Issues are there are 256 8 bit opcodes and 50+ (can't remember exact number) 16 bit opcodes. This would take a long time to do properly.
Write some sort of logging framework that logs a stacktrace at each operation and compares it to other established emulators. This would be pretty quick to do, and allows a fairly rapid overview of what exactly went wrong. The log file would look a bit like this:
...
PC = 212 Just executed opcode 7c - Register: AF: 5 30 BC: 0 13 HL: 5 ce DE: 1 cd SP: ffad
PC = 213 Just executed opcode 12 - Register: AF: 5 30 BC: 0 13 HL: 5 ce DE: 1 cd SP: ffad
...
Cons are I need to modify the source of another emulator to output the same form. And there's no guarantee the opcode is correct as it assumes the other emulator is.
What else should I consider?
Here is my code if it helps: https://github.com/dbousamra/scalagb
You could use already established test roms. I would recommend Blargg's test roms. You can get them from here: http://gbdev.gg8.se/files/roms/blargg-gb-tests/.
To me the best idea is the one you already mentioned:
take an existing emulator that is well known and you have the source code. let's call it master emulator
take some ROM that you can use to test
test these ROMs in the emulator that is known to work well.
modify the master emulator so it produces log while it is running for each opcode that it executes.
do the same in your own emulator
compare the output
I think this one has more advantage:
you will have the log file from a good emulator
the outcome of the test can be evaluated much faster
you can use more than one emulator
you can go deeper later like putting memory to the log and see the differences between the two implementations.
I'm currently working on hooking ntdll.dll calls via dll injection.
At first, I create thread in existing process via CreateRemoteThread() then I load my dll via LoadLibrary and finally hook calls on PROCESS_ATTACH.
Injection works fine, but then I want to log all registry and file system queries. And the problem is that it doesn't work properly.
I decided to publish code via PasteBin, because piece is pretty big. Here is the link:
http://pastebin.com/39r4Me6B
I'm trying to hook ZwOpenKey, then log key content and then launch "true" function by pointer. Function NOpenKey gets executed, but process stops without any errors.
Does anyone see any issues?
If you use OllyDbg, ZwOpenKey starts with 5 bytes MOV EAX, 77.
You can overwrite these bytes like so JMP _myZwOpenKey then from there you can do whatever with the values on the stack, restore all registers then do a JMP 7C90D5B5 which is address of ZwOpenKey + 5 bytes.
CPU Disasm
Address Hex dump Command Comments
7C90D5AF 90 NOP
7C90D5B0 /$ B8 77000000 MOV EAX,77 ; ntdll.ZwOpenKey(guessed rg1,Arg2,Arg3)
7C90D5B5 |. BA 0003FE7F MOV EDX,7FFE0300
7C90D5BA |. FF12 CALL DWORD PTR DS:[EDX]
7C90D5BC \. C2 0C00 RETN 0C
I usually do these in Assembly that way I don't have to mess around a lot with type casting and all that. Hope this helps.