Linker problems between asm and c objects

[R3DC0DE]

Hello,

Back again for another linker problem. So I am trying to compile my idt but, for reason I don't understand, it seems the code in interrupt.asm and the code from idt.c/.h ignores each others. Even though I linked them. I must be linking the two of them wrong.

Here is the git : https://github.com/MrScriptX/OS/tree/interrupt/cpu

Also, while I'm at it. Isn't it better to build the idt in asm directly. If so, how should I tackle this ?

Thanks

[Octocontrabass]

Why aren't you using a cross-compiler? You should be using a cross-compiler.

I suspect the problem you're having is that GCC automatically adds a prefix to symbols in order to meet the requirements of the Windows ABI, but I can't tell for sure without the error messages from the linker.

[R3DC0DE]

Why aren't you using a cross-compiler? You should be using a cross-compiler.

I suspect the problem you're having is that GCC automatically adds a prefix to symbols in order to meet the requirements of the Windows ABI, but I can't tell for sure without the error messages from the linker.

Here are the errors : cpu/idt.o:idt.c:(.text+0x7):

undefined reference to `interrupt_handler_0' //(doings this for every interrupt_handler)
cpu/interrupt.o:cpu/interrupt.asm:(.text+0x12): undefined reference to `interrupt_handler'

[iansjack]

Why have you put the "extern" directive in brackets?

[iansjack]

It seems that you need to use underscores for global symbol names in the assembler file to fit with the Windows ABI.

https://www.nasm.us/doc/nasmdoc9.html

[Solar]

• Use a cross compiler to avoid system-ABI specific issues creeping in, and allows you to handle your objects with the (much better equipped) ELF toolchain.
• Use the ABI documentation for the ABI you're using to figure out conventions. C/C++ does a couple of things with symbols that aren't readily apparent just from the source, and your ASM code needs to follow the same rules.
• Know how to use your toolchain. In this case, know how to display the symbols in your object code -- both the ones defined, and the one referenced. This makes it easy(-er) to figure out why the two don't match. But, with regards to the previous point, don't play trial & error -- know the rules.

[iansjack]

I agree that you would be far better off using ELF object files. Apart from any other advantage, this is what almost all examples you will see assume.

I've nothing against using Windows as a development environment (although I abandoned it ages ago) but you need to be fully aware of what you are doing and will find it harder to follow example code. If using Windows you would be far better off using the Windows Linux subsystem rather than messing about with minwgcc, etc.

[R3DC0DE]

Thank you for your answers. I will play around a bit to see how everything work.