newest idea:
i gave up playing around with the little test-code and went over to the real conditions. i made a small 16bit-init-code (clear memory, enable a20, copy gdt, load gdt) which jumps into the c-code. you might guess it, i fail.
newest try:
i tried the whole thing with jloc instead of ld. i think i understood how the controlfile and the map-file work, but jloc generates completely wrong adresses.
for example in at the end of the assembler-init-code i have a "jmp _init@0", but the adress jloc references to is 00000000 (so, base+offset+relative jump = 00000000); obviously jloc seems to calculate something, but it somehow believes that the void init() is at 00000000... (no need to think about that, i'm just reporting).
another try:
ld links somehow correct (i think, don't rememer exactly), but i have to output into a pe-file and strip the code into binary with objcopy. the output is 5kb, but the code is in binary as i wanted - leaving soo much space between the code of the obj-files... any way to prevent this? can i tell ld the order of the obj-files?
and: gcc doesn't support that nice inline-assembly, eh?
i gave up playing around with the little test-code and went over to the real conditions. i made a small 16bit-init-code (clear memory, enable a20, copy gdt, load gdt) which jumps into the c-code. you might guess it, i fail.
newest try:
i tried the whole thing with jloc instead of ld. i think i understood how the controlfile and the map-file work, but jloc generates completely wrong adresses.
for example in at the end of the assembler-init-code i have a "jmp _init@0", but the adress jloc references to is 00000000 (so, base+offset+relative jump = 00000000); obviously jloc seems to calculate something, but it somehow believes that the void init() is at 00000000... (no need to think about that, i'm just reporting).
another try:
ld links somehow correct (i think, don't rememer exactly), but i have to output into a pe-file and strip the code into binary with objcopy. the output is 5kb, but the code is in binary as i wanted - leaving soo much space between the code of the obj-files... any way to prevent this? can i tell ld the order of the obj-files?
and: gcc doesn't support that nice inline-assembly, eh?
Check my JLOC control file inside SOLOS source code ;)
It might give you some ideas, but you must know the segments generated by your c++ compiler
It might give you some ideas, but you must know the segments generated by your c++ compiler
well, since i can't send files via pm i post the kernel.o (generated from kernel1.zip) for hgb.
i played around with jloc as well, getting just useless output (even if linking just 2 c-files (gnu coff-output), one function calling the other in another file...) when i try with fasm (format coff) the output is completely correct
are the MS COFF-files wrong for jloc? (well, i think so)
it just seems difficult to get a binary output...
hgb: what i meant was inline assembly in intel-format, like the visual-cpp-compiler (not the at&t-style i don't like...)
i played around with jloc as well, getting just useless output (even if linking just 2 c-files (gnu coff-output), one function calling the other in another file...) when i try with fasm (format coff) the output is completely correct
are the MS COFF-files wrong for jloc? (well, i think so)
it just seems difficult to get a binary output...
hgb: what i meant was inline assembly in intel-format, like the visual-cpp-compiler (not the at&t-style i don't like...)
i played around with jloc as well, getting just useless output (even if linking just 2 c-files (gnu coff-output), one function calling the other in another file...) when i try with fasm (format coff) the output is completely correct
are the MS COFF-files wrong for jloc? (well, i think so)
If jloc works with fasm output but not gnu, then it's more likely it's the GNU coff format it chokes on... probably the relocation stuff that screws stuff up.
Still think it's weird you're having all this trouble, wasn't too hard to get working for me 'back in the days' :P
Newer versions of GAS supports intel-style assembly, so GCC might support it inline too? Read compiler docs.
i've just managed to enter the c-code from a fasm-init code; so what i'll do now is to write the initialisation-code (copy gdt, create idt, enter pm, create pagetable, enable paging) in fasm as i did it before too; then i'll enter the c-code with paging enabled at 0xF0000000 base.
since there's only one transfer from fasm to gcc it sould work then.
i'll need some time to accomplish this (since i have other things to do), but you'll hear me screaming if it works :tongue: (ok, i'll post the results here as well :))
since there's only one transfer from fasm to gcc it sould work then.
i'll need some time to accomplish this (since i have other things to do), but you'll hear me screaming if it works :tongue: (ok, i'll post the results here as well :))
Nice, I test the o file that you put, the error tht I get is the same that I say before, that is be a no specification of the assembler that the symbol start is global.... or if you prefer, there in the original file, dosent exist a mark that say the symbol is "public".
the error that I get from your kernel.o is the same that I obtain when I not add the line "global start" in the asm file.
By the way, I attach the kernel.o assembled with nasm and that have added the line global start ld no giveme errors with this file.
Still working.
Have a nice day or night.
the error that I get from your kernel.o is the same that I obtain when I not add the line "global start" in the asm file.
By the way, I attach the kernel.o assembled with nasm and that have added the line global start ld no giveme errors with this file.
Still working.
Have a nice day or night.
hmmm, obviously the only difference between your file, hgb and mine is at adress 0x28; you have 0x05 there and i 0x04.
i've played around with a minimal-core and got the entry from fasm into gcc-code; i'm so glad - it works, somehow; i even can do classes which are built onto the stack. i hope i can relocate the gcc-part to 0xF0000000 (so that jloc makes it correct - once you understand jloc its so powerful)
i've played around with a minimal-core and got the entry from fasm into gcc-code; i'm so glad - it works, somehow; i even can do classes which are built onto the stack. i hope i can relocate the gcc-part to 0xF0000000 (so that jloc makes it correct - once you understand jloc its so powerful)
well, a final word: i think it's done.
i started recoding the whole kernel beginning with the memory management (which works now) and now go on with the main gui-functions. everything is in classes now (CMemory, CScreen), i don't know if its the perfect solution i've been searching for (the compiler has to push the adress of the class for every function...).
the solution was now to use fasm for the asm-initializing-stuff and one c-file compiled with gcc (two made incorrect offsets for all references of the second file...).
well, thanks for all replies; you brought me back to os-coding i paused half a year ago.
i started recoding the whole kernel beginning with the memory management (which works now) and now go on with the main gui-functions. everything is in classes now (CMemory, CScreen), i don't know if its the perfect solution i've been searching for (the compiler has to push the adress of the class for every function...).
the solution was now to use fasm for the asm-initializing-stuff and one c-file compiled with gcc (two made incorrect offsets for all references of the second file...).
well, thanks for all replies; you brought me back to os-coding i paused half a year ago.