flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > Linking and Calling C function from Assembly |
Author |
|
revolution 16 Nov 2019, 09:37
Firstly I'm not good with C, so this might be wrong.
But, when you write a boot sector you don't define an entry point because the output format should be a binary file. That is, it won't be an exe format, so there is no way to define an entry point. The BIOS will simply jump to the first byte of the sector. |
|||
16 Nov 2019, 09:37 |
|
dhavalhirdhav 16 Nov 2019, 09:38
revolution wrote: Firstly I'm not good with C, so this might be wrong. Thanks for your reply. I do not have issue with boot sector. Boot sector works fine. Goes into protected. |
|||
16 Nov 2019, 09:38 |
|
revolution 16 Nov 2019, 09:41
But you are now trying to link with your boot sector. So the linker wants to know the entry point. But there is no way to define it.
Perhaps you can make a dummy entry point to satisfy the linker. It won't matter what you make it since it is never used. |
|||
16 Nov 2019, 09:41 |
|
dhavalhirdhav 16 Nov 2019, 09:44
revolution wrote: But you are now trying to link with your boot sector. So the linker wants to know the entry point. But there is no way to define it. aah ok.. that makes sense. I modified my code like this: Code: format COFF use32 public main as '_main' extrn _start main: call _start and c code as follows: Code: #include <stdio.h> extern void __cdecl start() { printf ("test"); } This works.. linker is not complaining now. It produces .exe file. .which is Windows executable.. executes but doesnt show any output on screen. I will see how I can produce obj file out of linker so that I can load that into memory through boot sector. |
|||
16 Nov 2019, 09:44 |
|
revolution 16 Nov 2019, 09:47
What library are you using for printf?
Also, I would recommend you make a binary file. Loading obj files is quite tricky. You could do it, but it makes the boot sector needlessly complex. |
|||
16 Nov 2019, 09:47 |
|
dhavalhirdhav 16 Nov 2019, 09:55
revolution wrote: What library are you using for printf? stdio.h Quote:
Any idea how do I produce binary file with fasm and with c compiler? Binary file as in bin files? If I do bin files in fasm.. I cant use extern keyword right? |
|||
16 Nov 2019, 09:55 |
|
revolution 16 Nov 2019, 10:03
stdio.h is for the OS binding. I don't think C has a BIOS version of stdio.
I think to make your binary you would first link the obj files so that the symbol binding is done at that stage. And then you convert it to a binary as the last step. |
|||
16 Nov 2019, 10:03 |
|
dhavalhirdhav 16 Nov 2019, 10:09
revolution wrote: stdio.h is for the OS binding. I don't think C has a BIOS version of stdio. hmm.. is there any good example of using FASM boot sector to call c method / function? |
|||
16 Nov 2019, 10:09 |
|
revolution 16 Nov 2019, 10:15
You don't really need to link your boot sector with the second stage.
You can make your second stage binary have its entry point as the first byte. Or just put a pointer at the first dword and your boot sector can read that to jump to the entry. |
|||
16 Nov 2019, 10:15 |
|
dhavalhirdhav 16 Nov 2019, 10:48
revolution wrote: You don't really need to link your boot sector with the second stage. yes thats what I have done.. my boot sector reads 2nd sector of drive and loads it into memory and jumps to 2nd sector's entry point. I dont link boot sector and second stage.. but now what I want to do is, I dont want to continue with ASM as it will be too difficult, so I want to write kernel in C and 2nd stage should jump to C method. |
|||
16 Nov 2019, 10:48 |
|
revolution 16 Nov 2019, 10:52
I was assuming your C code was the second stage. But my comment can still apply if your C code is some other stage. If you only have one symbol to bind then it is quite easy to do. And that way you can update each stage individually without affecting the other stages.
|
|||
16 Nov 2019, 10:52 |
|
dhavalhirdhav 16 Nov 2019, 11:00
revolution wrote: I was assuming your C code was the second stage. But my comment can still apply if your C code is some other stage. If you only have one symbol to bind then it is quite easy to do. And that way you can update each stage individually without affecting the other stages. ok.. any pointers.. I have been trying to link since many days and progressing very slow |
|||
16 Nov 2019, 11:00 |
|
revolution 16 Nov 2019, 11:11
If we assume your boot sector is at 0:7c00 and you load the second stage C code at 0x10000 then do this:
Code: use32 ;... jmp 0x10000 ;jump to the first byte and start executing Code: use32 ;... mov eax,[0x10000] ;read the offset add eax,0x10000 ;add the load address jmp eax ;execute |
|||
16 Nov 2019, 11:11 |
|
dhavalhirdhav 16 Nov 2019, 13:22
revolution wrote: If we assume your boot sector is at 0:7c00 and you load the second stage C code at 0x10000 then do this: ok.. I first need to figure out way to convert obj file into bin files. |
|||
16 Nov 2019, 13:22 |
|
BAiC 16 Nov 2019, 21:38
found this. it's in nasm but if fasm produces object files that are compatible then it should work the same.
https://www.devdungeon.com/content/how-mix-c-and-assembly |
|||
16 Nov 2019, 21:38 |
|
dhavalhirdhav 18 Nov 2019, 03:43
BAiC wrote: found this. it's in nasm but if fasm produces object files that are compatible then it should work the same. yes.. I did it with NASM and gcc linker finally. I really wish FASM could do that. |
|||
18 Nov 2019, 03:43 |
|
edfed 18 Nov 2019, 09:25
maybe you can twist this example https://flatassembler.net/examples/msvc.zip to make what you'd like.
here, the c code will call asm code that will call c code. |
|||
18 Nov 2019, 09:25 |
|
donn 18 Nov 2019, 17:18
If you're just building a COFF and mixing with C, think the 32-bit imports look like this:
Code: extrn '__imp__HeapAlloc@12' as HeapAlloc:dword 64 is different. The link just provided above should have another import example in there somewhere. msvc is what got me started with COFFs. I think @12 relates to the parameter count sizes. 64 bit does not need them.[/code] |
|||
18 Nov 2019, 17:18 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.