ASM Community

Try and use John Fine's JLOC ...

I would have also suggested FASM (or waiting for SOL_ASM) but he wanted a c/c++ solution.

I also thing anything else but ASM is an overkill and in most cases no way easyer ... just a mind ideea that is easyer ... but it is his choice and i respect it.

I course C++ typecasting every little day i work :D

Instead of helping me find mistakes it is mostly slowing me down and making me search for axes nearby

I do not see any use for C++ and clases other than fancy IDE and the fact that they want to hide that there are structures with function pointers inside...and that is not nice structured programming isnt it :rolleyes:

Somehow the humman race considers that hideing and lieing is a very nice and good thing...

hartyl,

If you are looking for a free C/C++ compiler, you can try Pelle's C, Digital Mars, Blodshed and Open Watcom.

good information you're giving me. i've tried to make it with the gcc compiler and the ld linker the easiest way (a minimal code to see it working).
i have 2 files and want to link the together while one file uses functions of the other. it looks like this:

//boot.cpp

extern "C"

{ void core();

}



int foo_bar(unsigned long foo);



void main()

{ int x=foo_bar(1);

  core();

}



int foo_bar(unsigned long foo)

{ return (int)(foo-1);

}



------------------------------------



//core.cpp

extern "C"

{ int foo_bar(unsigned long);

}





void core()

{ foo_bar(1);

}

i compile to object-files like this:

gcc boot.cpp -c

gcc core.cpp -c

but when linking i get the error:

>ld boot.o core.o -e _main



boot.o(.text+0x7):boot.cpp: undefined reference to `__main'

boot.o(.text+0x1e):boot.cpp: undefined reference to `core'

core.o(.text+0xc):core.cpp: undefined reference to `foo_bar'

why doesn't it work? why can't the linker find my references between the object-files?
(addition: i have never done self-linking before...)
(another addition: ld just crashes when i use "--oformat binary"... - another "why?!")

omg! deleting a kernel? :D

you're brilliant; didn't know that the exported functions have to appear also in the "extern C"-block - learnt something :D

it works even more than before; i got dev-cpp, the newest version with the "ld"-linker. that version doesnt crash when i use the "--oformat binary", but it doesnt work either giving me this error:
"PE operations on non PE file."
cruel, isn't it?

you might already know my answer:
i have no idea how the script works, what the syntax is like, where the obj-files are specified.
the code looks nice, but where is the __KERNEL_ENTRY__ defined? is it a symbol? if you output in binary, where do the section-names appear (actually the aren't used, are they?)? maybe a complete reference of the script and its syntax?

how does the ld-linker react on ms-coff obj-files?

i'll play around with this script, maybe i get a good result.

thanks at all; i'll tell you what i got then :)

The input files aren't specified in the linker script (they can be, though) - I use the linker script to control the order of sections, plus add some symbols. Specify .obj and .lib on commandline.

__KERNEL_ENTRY__ is defined in one of my .c files (or perhaps a .asm one, can't remember). It may seem a bit pointless including it, but iirc ld bitches if you don't have an entrypoint - even for binary output.

The section-names appear nowhere, but it's nice being able to control the order they appear in the binary output.

For a reference of the script, your best bet is probably unix "info ld" or go to http://www.delorie.com/djgpp/ and get the 32bit dos extended djgpp, as it has the texinfo program + docs on ld.


Good question. DJGPP uses the gnu-coff or dj-coff or whatever... dunno if perhaps mingw32 supports ms-coff? The only difference I encountered between the two formats were with regards to relocations. In the MS format, the code has a dword 0 and the linker does the entire relocation, in the other format it has a value where the relocation delta will be applied.

I'd still advise you to use PE or ELF for your kernel, but getting binary kernel loading to work first is probably a good idea :)

Hgb,

I'd much rather use masm than gas - or well, perhaps gas is okay after they added intel syntax. I don't do "high-level" coding in assembly anyway, so I tend to prefer nasm or fasm, since they do what I want them to.

Hi f0dder,

Do you know if there is any specification/reference for the MS COFF obj file and lib format?

man, i start hating it; so much good information, and i still keep failing.
i went to level 0, i got kernel1.zip (posted by hgb) and used exactly the tools used for that example. the gcc-compiler and ld-linker are from the dev-cpp-binaries (newest i think) and i got the newest nasmw as well. then i exectued the kernelbuild.bat, where the compiler does its work, the assembler as well, but the linker just outputs a message complaining about the object file from nasmw:

C:\Dev-Cpp\bin>kernelbuild



C:\Dev-Cpp\bin>nasmw -f aout kernel.asm -o kernel.o



C:\Dev-Cpp\bin>ld -T kernel.ld kernel.o

kernel.o: file not recognized: File format not recognized

if i use another file-format (coff,obj,win32) i get "PE operation on non PE file."

this can't be true?! or am i predicted to failing using windows for developing my system (do the linux-assembler/compiler/linker-versions behave differently?)

hmm, somehow i don't thrust the output of nasm


nah, that's the reason why i want to do it the obj-file-way; i can't make any references to the c-files when i just make a binary assembler-code.

the linker gives the same error if i try the obj-files from fasm (MS COFF, COFF or ELF)...

either i give the whole thing up, or i have the do it a dirty way, i think