Inline Assembler confusing warnings

[Seltsamuel]

Hi,

some things i noticed with the inline assembler:

void __declspec(naked) Test_Func(void)
{
   __asm
   {
      mov eax,[0x6fb7f108]
      jmp eax
   }
}

this one generates this message: - warning: Internal error: build_cfg()
The warning is because of the JMP i could isolate it there but i dont know what build_cfg() is its not from me


This one is a Callstub:
char* Teststub(char *filename)
{
   __asm
   {
      mov ESI, filename
      call [Testfunc2]
   };

};

The return comes from Testfunc2 but PellesC complains: - warning #2096: Missing return value.
Is it a Bug ? how can i tell PellesC about the return inside inline assembly ?

All in all this releasecandidate performs verry well good work!

Greetings

Seltsamuel

[Pelle]

1. "Internal error: build_cfg()" is a last-chance warning that the compiler can't build a control-flow graph of the function (in this case because of 'jmp reg' - generally impossible to tell where the jump is going); The message could be better, but I'm not going to be bothered changing it any time soon (it can really only happen for odd inline assembly code, and using the external assembler will always be a billion times cleaner...)

2. There is not a single return statement/instruction in this function, so the warning is perfectly fine. You can use #pragma warn to shut up the warning.

[Seltsamuel]

Hi,

the external assembler is in my case no option :-) im glueing c and assembly together to get access to assemblyinstructions from inside my c code. Technically im building a interface to external code.

Jumptables using registers are often seen in assembly but im fine with the warning, now i know what it means and that there is no real problem with it.

Ok i will ingnore this warnings because turning off any warning is most times no wise decision :-) is there any cleaner way to tell the compiler that the return is set inside EAX from inline assembly only for this single function ?

So far thanks for your answers

Seltsamuel

[Synfire]

Ok i will ingnore this warnings because turning off any warning is most times no wise decision :-) is there any cleaner way to tell the compiler that the return is set inside EAX from inline assembly only for this single function ?

So far thanks for your answers

Seltsamuel

Code: [Select]

char* Teststub(char *filename)
{

   /*** Eax is the default return value anyways, just add a 'RET' to the end. ***/
   __asm
   {
      Mov Esi, filename
      Call [Testfunc2]
      Ret
   };
}

[Seltsamuel]

Hi,

thanks for your post, but wont this force the compiler to create 2 times a ret ? The compiler should create a ret anyway because the function is not __declspec(naked) and ends.

Hmmm maybe im simply too much looking at resources a simple ret wont do any harm and it should do the dirty deed as expected.

Greetings

Seltsamuel

[Vortex]

Hi Seltsamuel,

You can terminate an inline asm function with the return statement :

Code: [Select]

#include <stdio.h>

#define a 97
#define z 122

char *szUpper(char *text)
{
__asm{
mov eax, text
dec eax

@repeat:

add eax, 1
cmp BYTE PTR [eax], 0
je @end
cmp BYTE PTR [eax], a
jb @repeat
cmp BYTE PTR [eax], z
ja @repeat
sub BYTE PTR [eax], 32
jmp @repeat

@end:

}
return text;
}

int main(int argc,char *argv[])
{
char message[]="string converted to uppercase";
printf("%s",szUpper(message));
return 0;
}


[Seltsamuel]

Hi,

thx Vortex, in your case this is obvious but not in mine.
The EAX is set because of a call to a external function and return eax isnt a valid syntax ;-)
so it seems i will stick with the ret opcode.

Greetings

Seltsamuel

[Synfire]

Sorry for the late reply, as I'm sure most people who know me can tell you I only really drop by here when I have the privilege to be on a windows machine in which time I get to actually use Pelles C.

If you want to be absolutely certain that no extra RET opcodes are going to be generated you can make use of the __declspec(naked) option. Check the example below.

Code: [Select]

#include <stdio.h>

__declspec( naked ) int safe_div( int a, int b )
{
__asm {
Push Ebp
Mov Ebp, Esp
Stc
Xor Edx, Edx
Xor Eax, Eax
Mov Ecx, b
Or Ecx, Ecx
Jz @@div_err
Mov Eax, a
Or Eax, Eax
Jz @@div_err
Div Ecx
Clc
@@div_err:
Leave
Ret
};
}
/*
00401000  /$ 55             PUSH EBP
00401001  |. 89E5           MOV EBP,ESP
00401003  |. F9             STC
00401004  |. 31D2           XOR EDX,EDX
00401006  |. 31C0           XOR EAX,EAX
00401008  |. 8B4D 0C        MOV ECX,DWORD PTR SS:[EBP+C]
0040100B  |. 09C9           OR ECX,ECX
0040100D  |. 74 0A          JE SHORT InlineAs.00401019
0040100F  |. 8B45 08        MOV EAX,DWORD PTR SS:[EBP+8]
00401012  |. 09C0           OR EAX,EAX
00401014  |. 74 03          JE SHORT InlineAs.00401019
00401016  |. F7F1           DIV ECX
00401018  |. F8             CLC
00401019  |> C9             LEAVE
0040101A  \. C3             RETN
 */

int main ( void )
{
int test1, test2, test3;
test1 = safe_div( 0, 3 );
test2 = safe_div( 3, 0 );
test3 = safe_div( 20, 4 );
printf ( "test1: %d\ntest2: %d\ntest3: %d\n", test1, test2, test3 );
return ( 0 );
}
And the output:

test1: 0
test2: 0
test3: 5

As you can see from the OllyDBG disassembly of the procedure it doesn't include any extra RET's.. HOWEVER! keep in mind that using __declspec(naked) you will need to setup your own stack frame and preserve any registers if needed yourself. __declspec(naked) basically tells the compiler that you just want a label and that you will deal with the stack setup/destruction yourself. As you can see, you are still able to make use of variable arguments and such, so that does make thing a bit nicer.

Regards,
Bryant Keller

[TimoVJL]

How about testing PellesC IDE in linux with wine.

[Synfire]

Although I'm almost certain it would work, I'm more of a NASM programmer. This makes SciTE a preferred editor on GNU/Linux for me as it's easily customizable to support my favorite assembler while still supporting C/C++. On Windows, since I do much more C than C++, Pelles C is my favored environment over IDEs like MSVS which is way too bloated and DevC++ which is really hacked together (crashes a lot). If I end up in a situation in which a project is "getting out of hand" and needs better project management than what SciTE offers I use Geany, but that tends to be a rarity due to my coding style.

[Seltsamuel]

Hi,

thanks for the answers, building an own stackframe would be the solution.

@timovjl
PellesC works well with Wine im using it when i programm under Linux for Windows ^^. The glitches are only minor.

When i want to make Linux native Code i use KDevelop or simply vi ;-)

Greetings

Seltsamuel

[AlexN]

How about testing PellesC IDE in linux with wine.

A long time ago CHristian has tried it successful. See http://forum.pellesc.de/index.php?topic=2466.0