Wrong call addresses with MinGW

[Oxyd]

I'm trying to get a basic kernel to work. It's in elf format. The problem is, that the call addresses are wrong. Disassembly shows that they are shifted down (the called address is bigger, than the address of the function to be called). The offsets are not equal, but they grow by 0xF bytes (first call is 0xF bytes wrong, next one is 2 * 0xF, ...).

I'm using NASM to compile the assembly sources and gcc (3.3.1, MinGW) to compile the .c sources. Linked using ld (2.11.2).

Oxyd

[ich_will]

Try to call the linker with the option --omagic. I don't know but it might help.

[Oxyd]

Didn't work... :-\

I was thinking, wheter it wasn't because of the elf format (some kind of relocation, or whatever), so I tried to compile it into plain binary, but the problem was still there...

It is interesting, that if I use a function pointer to call the function, the call works fine...

Oxyd

[Oxyd]

So far, I've managed to discover, that source as simple as:

Code: Select all

void kernelMain (void)
{
    kernelConsole_init ();
    while (1);
}

Is compiled into the object file as

Code: Select all

0: push ebp
1: mov  ebp, esp
3: sub  esp, 8
6: call b
b: jmp  b

But when I program the same in assembly (NASM) and assemble it into the .o file, the call is not call b, but call 0... With "call 0" it runs fine...

So, it must be something with the GCC... I wonder, wheter there's some switch or something, that would force the GCC produce the same code as nasm would... I've searched the documentation, but I haven't found anything, myself.

[df]

uh, because the .o file is an object file, not executable code. compiling that next step creates the symbol addresses...

[Oxyd]

I know, it's not the final result, but when the .o contains the call 0 instruction, it's linked as perfectly functional binary. If it contains call b, it's linked into something unexecutable.

And if I type the same code in C and assembly (assuming, it's simple enough, so the compiler doesn't do any too fancy optimalization) and run it through compiler / assembler, I'd expect the same output...

Oxyd

[Chris Giese]

MinGW is a piece of crap. It's ELF support has _never_ worked properly, and this is just one of many bugs.

If you really want ELF, install Linux and use Linux GCC. If you stick with MinGW, use PE COFF and avoid ELF completely. There isn't really a compelling reason to chose one file format over the other.

And this is interesting: http://UnxUtils.sourceforge.net/

No CYGWIN1.DLL. No MSYS-1.0.DLL. What do these guys know that the CygWin and MinGW developers don't?

[Oxyd]

Oh... Compiled into PE and it works... Thanks Chris

Oxyd

[Solar]

No CYGWIN1.DLL. No MSYS-1.0.DLL. What do these guys know that the CygWin and MinGW developers don't?

Why, isn't that what MinGW is supposed to churn out - standalone W32 apps?