So, int a = test() is not enough you are saying? Let me see what happens if I do int a = test(); c = a * b;

I just tried int c = a * 2; and the routine is still just RETN 10;

Well we haven't seen you full code. But I assume that you did not use the return value so the compiler thought it would be smart to not even bother to include the instruction mov eax,4. When you put volatile then you tell the compiler that "someone else needs this value so don't forget to set it properly".

Quote:

So, int a = test() is not enough you are saying? Let me see what happens if I do int a = test(); c = a * b;

I just tried int c = a * 2; and the routine is still just RETN 10;

Heh... and did you use "c"? By "use" I mean something that compiler can not discover is efectless part of your app. Best way to test optimization of procedure is to compile the procedure into separate object file, and then disassemble that object file. But that can't be done with olly, unfortunatelly.

/O1 /Oi /GL /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /GF /FD /EHsc /MT /GS- /Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt    

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int test()
{
srand ( time(NULL) );
return (rand() % 10 + 1);
}

int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
int a = test();
printf("%d",a);
}    

CPU Disasm
Address   Hex dump          Command                                  Comments
00401000  /$  6A 00         PUSH 0                                   ; test.00401000(guessed Arg1,Arg2,Arg3,Arg4)
00401002  |.  E8 1C010000   CALL 00401123
00401007  |.  50            PUSH EAX
00401008  |.  E8 E2000000   CALL 004010EF
0040100D  |.  E8 EF000000   CALL 00401101                            ; [test.00401101
00401012  |.  6A 0A         PUSH 0A
00401014  |.  59            POP ECX
00401015  |.  99            CDQ
00401016  |.  F7F9          IDIV ECX
00401018  |.  42            INC EDX
00401019  |.  52            PUSH EDX
0040101A  |.  68 6CB34000   PUSH OFFSET 0040B36C                     ; ASCII "%d"
0040101F  |.  E8 06000000   CALL 0040102A
00401024  |.  83C4 10       ADD ESP,10
00401027  \.  C2 1000       RETN 10    

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int test()
{
srand ( time(NULL) );
return (rand() % 10 + 1);
}

int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
int a = test();
//printf("%d",a);
}    

CPU Disasm
Address   Hex dump          Command                                  Comments
00401000  /$  6A 00         PUSH 0                                   ; test.00401000(guessed Arg1,Arg2,Arg3,Arg4)
00401002  |.  E8 44000000   CALL 0040104B
00401007  |.  50            PUSH EAX                                 ; /Arg1
00401008  |.  E8 0A000000   CALL 00401017                            ; \test.00401017
0040100D  |.  59            POP ECX
0040100E  |.  59            POP ECX
0040100F  |.  E8 15000000   CALL 00401029
00401014  \.  C2 1000       RETN 10    

I think it was because I didn't really use it but the compiler was making a nasty assumption since I assigned the return value to a variable. If I used volatile it was forced to allow it otherwise it simply ignored it.

What catches my eye is all of those calls because there is nothing to call since this is the section that was called and printf was commented out.

The subroutine resides at 401000 as I have it forced to be static for this testing

For the fastest and tightest code what should the compile options be that will still work with any FASM code I write? Remember I do not do this via command line I do it inside Visualstudio but that shouldn't matter.

My bad, I misread the following:

DarkAlchemist wrote:

The subroutine resides at 401000 as I have it forced to be static for this testing

I thought you meant you added the static keyword to the function definition, which means it can only be used inside the current source module (and thus lets the compiler optimize more aggressively) - I take it that what you meant is you build a FIXED executable, ie one without relocations?

Btw, "going all over the place" should only happen at runtime, and is a decent security enhancement known as ASLR. It's another reason why you should look at disassemblies or generated assembly listings rather than inspecting runtime code

Address space randomization hinders some types of security attacks by making it more difficult for an attacker to predict target addresses. For example, attackers trying to execute return-to-libc attacks must locate the code to be executed, while other attackers trying to execute shellcode injected on the stack have to first find the stack. In both cases, the related memory addresses are obscured from the attackers. These values have to be guessed, and a mistaken guess is not usually recoverable due to the application crashing.

As for the previous "1, 2, 3, 4 doesn't show up in the assembly output", can you show the minimal amount of C code plus compiler settings to make that happen? (following the advice I gave earlier on only putting that function in your .c file, and doing a compile-only build).

I prefer to look at the loaded code to see exactly what is happening not what should, or could, be happening. As far as security goes

in Windows I can find where a program is at virtually and is actually at in memory so this relocation randomization stuff isn't much of a security enhancement.

I don't think it is needed, now, because I wasn't "really using it" because the compile saw that I was assigning int a to the return value but that was not enough to force it to do it I actually had to use the integer variable 'A' before it threw out a piece of code that wasn't very optimized. The fact that it pushed ecx then stored 4 on the stack and pop ecx instead of just mov ecx, 4. Not very optimized at the minimum.