OSDev.org

Hi all.

I have MinGW and Nasm linkage problems : when I have 2 files ( 1 - C, 2 - ASM ), and they have cross-references ld links it wrong.
After linkage call to _foo1 is to other address (wrong). So Bochs and VMWare stops when I try to execute.

P.S.
MinGW/GCC 3.4.2, NASM 0.98.39
object format COFF.

Actual sources is too big to place it here.

Thanks.

There have been people with similar problems, usually where C mangles the names of the functions/looks for mangled function names in the asm file. There is an option to make it look for the correct names which you need to enable though I can't remember it off-hand. A quick search should sort you out, or look somewhere in the two pages or so of posts as there was a recent one.

Edit:
Reading your post again I notice that your code actually compiles but runs incorrectly. Sorry. Are your segment registers correct when it is running?

Are your segment registers correct when it is running?

My segment registers are correct. I have 100% linking problem, when I disassemble my file, I've found that calls goes to strange addresses ( i.e. to a middle of functions ).

Thanks.

I have just changed my C compiler from OpenWatcom C 1.3 to MinGW/GCC 3.4.2

maybe your load address is not exactly the expected target address. what kind of target binary format do you use ? and what loader ?

maybe your load address is not exactly the expected target address

Load address is ok. It's works at all, till I call asm function which have reference to c.

what kind of target binary format do you use ? and what loader ?

This program is a loader.
I use my own executable format (for my OS loader) which consist of two parts:

1. DOS-COM 16 bit Real mode part.
2. PE-like 32-bit part.

It's works when I compile and link it with OpenWatcom
but with MinGW/GCC and NASM I have linking problems with cross-references from assembler parts.

Does some one had similar problems ? Help me !

Thanks.

you might like to check the output of "objdump -x yourkernelcoff.o" and make sure the preferred address is the one you assume. Both compilers might have different defaults.

To: Pype.Clicker

Thanks for your help.

May You give me Your e-mail and I'll send You my sources.
And You take a look at what I'am doing wrong.

Of coz if You have MinGW and NASM.

Thanks again.

On my earlier OS Expedition i had problems with MinGW (I cant recall what they were, but noone knew why I kept getting that error). Thus i got frustrated and gave up until now.


This time i tried using DJGPP, and it works like a charm. Ill try MinGW later today to see if it works or if i have a problem with it.

Possibly the compiler is taking shortcuts due to optimization, which breaks with C calling convention?
I read something about that earlier IIRC.
Try compiling with -O0.

>when I disassemble my file, I've found that calls goes to
strange addresses ( i.e. to a middle of functions ).

...

>On my earlier OS Expedition i had problems with MinGW (I cant recall what they were, but noone knew why I kept getting that error). Thus i got frustrated and gave up until now.
>
>This time i tried using DJGPP, and it works like a charm. Ill try MinGW later today to see if it works or if i have a problem with it.

I suspect a mix-up of DJGPP COFF and Win32 PE COFF. Object files in these two formats appear to be identical, but the relocations work differently.

This is especially insidious because the MinGW linker accepts DJGPP COFF object files without complaint (same for DJGPP linker with PE COFF object files).

Executive summary:
Use "nasm -f coff ..." with DJGPP
Use "nasm -f win32 ..." with MinGW or CygWin

If this turns out to be the solution, it'd definitely be something that should go into the FAQ.

CopperMan wrote: Of coz if You have MinGW and NASM.

unfortunately, i don't have MingW ...

Thanks to All.

I have changed output format from coff to win32 in nasm command line and it seems to work!

Thanks to All again !!!