OSDev.org

Well Here is the objdump results

main.o: file format pe-i386

Disassembly of section .text:

00000000 <___main>:
__main():
/res/osdev/sg-os/kernel/main.c:3
0:   55    push %ebp
1:   89 e5    mov %esp,%ebp
3:   5d    pop %ebp
4:   c3    ret
5:   4b    dec %ebx
   ...

00000007 <_main>:
main():
/res/osdev/sg-os/kernel/main.c:6
7:   55    push %ebp
8:   89 e5    mov %esp,%ebp
a:   83 ec 08    sub $0x8,%esp
d:   83 e4 f0    and $0xfffffff0,%esp
10:   b8 00 00 00 00    mov $0x0,%eax
15:   89 45 f8    mov %eax,0xfffffff8(%ebp)
18:   8b 45 f8    mov 0xfffffff8(%ebp),%eax
1b:   e8 00 00 00 00    call 20 <_main+0x19>
20:   e8 db ff ff ff    call 0 <___main>
/res/osdev/sg-os/kernel/main.c:7
25:   c7 45 fc 00 00 00 00    movl $0x0,0xfffffffc(%ebp)
/res/osdev/sg-os/kernel/main.c:9
2c:   c7 45 fc 00 80 0b 00    movl $0xb8000,0xfffffffc(%ebp)
/res/osdev/sg-os/kernel/main.c:11
33:   8b 55 fc    mov 0xfffffffc(%ebp),%edx
36:   b8 05 00 00 00    mov $0x5,%eax
3b:   88 02    mov %al,(%edx)
/res/osdev/sg-os/kernel/main.c:13
3d:   eb fe    jmp 3d <_main+0x36>
/res/osdev/sg-os/kernel/main.c:14
3f:   90    nop

I'm not sure exacly waht I'm looking for

Weird -- I haven't seen gcc do this. Apparently it's calling _alloca(0), to allocate zero bytes on the stack. I would link against libgcc.a to keep it happy.

There are two call instructions near the top of main: The first one has a zero displacement, which means it's a call to somewhere outside of this source file. This instruction will be patched by the linker. This is probably the call to _alloca.

The second one has a non-zero displacement. On the x86, gcc can generate position-independent code for calls and jmps within a source file, which means the linker doesn't need to relocate these calls. So even though this object file hasn't been linked, you can still see that the second instruction is a call to __main.

Right, it now works, I have writen my 'K' in display memory using C and it all works nicely.

Also Is it possible that I have found a bug in GCC 3.3.1 or I've heard that different versions can work slightly differently, could this be the reason for this.

Are there any language querks that I may come across. It's just when I tried using simple startup code in a Turbo C++ program that was loaded by a bootsector, for some reason if I tried to have pointers as funtion parameters, the values taht I tried to pass would be corrupted.

Thanks for all your help
srg

Each version of gcc seems to act differently in a random way. Normally that's OK, but we OS developers often need to work around each version's quirks.

libgcc.a should be located under somewhere your /lib directory. Locate it, and add its name to the linker command line after the object files.

Tim Robinson wrote: Each version of gcc seems to act differently in a random way.

To me that sounds like a very bad thing, that is sthe stuff of microsoft, I'd expect a lot more from such an important piece of software.

No, Microsoft would be to try to leave things as they are for backward compatibility. They would fix a couple of bugs in the IDE, but introduce more bugs than they fix.

The GNU way is to change everything, but make sure everyone knows that everything's changed, and make sure they recompile everything. Then, if anyone complains that something has broken, they ask "did you recompile the kernel and all the libraries?" and the user says "no".

just wondering ... wouldn't the 'standalone' and 'no-builtin' flags force GCC to work without alloca ?

You are bound to run into all kinds of such issues when your compiler is actually set up to create binaries for a completely different OS...

First thing I did was, setting up a GCC cross compiler targeting i586-elf (HOWTO: http://www.osdev.org/osfaq2/index.php/G ... s-Compiler). Even if you are targeting PE executables, you might want to build a dedicated compiler for your OS work, to avoid OS-specific includes like alloca()...

Then I did set the compile flags to the ones below, and had no problems so far. Note that I am using C++; the options below is a from-the-back-of-my-head subset of my C++ specific options. They might still contain some that won't make sense with C, and might miss some that would make sense.

Pype.Clicker wrote: just wondering ... wouldn't the 'standalone' and 'no-builtin' flags force GCC to work without alloca ?

Hey had no effect.

Solar wrote: You are bound to run into all kinds of such issues when your compiler is actually set up to create binaries for a completely different OS...

First thing I did was, setting up a GCC cross compiler targeting i586-elf (HOWTO: http://www.osdev.org/osfaq2/index.php/G ... s-Compiler). Even if you are targeting PE executables, you might want to build a dedicated compiler for your OS work, to avoid OS-specific includes like alloca()...

Then I did set the compile flags to the ones below, and had no problems so far. Note that I am using C++; the options below is a from-the-back-of-my-head subset of my C++ specific options. They might still contain some that won't make sense with C, and might miss some that would make sense.

Code: Select all

-nostdlib -nostartfiles -nodefaultlibs -Wall -Wno-deprecated -Wsign-promo -Werror

I tried building a cross compiler based on that FAQ targeting i386-elf, but I got errors a long way into the compile process.

I can't remember the errors off hand but I think they were Undclared identifier errors, not sure, so I gave up.

Anyway, It is working ok at the moment.

What I'm not sure of is how I'm going to build drivers for my os. I expect that they will be Kernel mode DLLs, I will be using the .drv extension (got the idea for the extension from Win3.1). Anyway I have no idea how I will do that yet.

Saying that, I'm no where near that point yet.

srg

..

crt0.o is kinda stub to a c program.

It fetches commandline args and environment variables and prepares the stack before calling int main(int argc,uchar_t **argv,uchar_t **envv); or similar. Very important this is for the execve(uchar_t *name,uchar_t **argv) call.

when main exits, it returns to crt0 where at last the exit() system call is executed.

That's roughly all about it.

just wondering ... wouldn't the 'standalone' and 'no-builtin' flags force GCC to work without alloca ?

They had no effect.

Form the bottom of How kernel, compiler and C library work together:

"alloca() is a stack probing procedure specific to Windows. alloca() is referenced in PE binaries, build e.g. by the Cygwin GCC. You can set -mno-stack-arg-probe to supress those references."

I tried building a cross compiler based on that FAQ targeting i386-elf, but I got errors a long way into the compile process.

I can't remember the errors off hand but I think they were Undclared identifier errors, not sure, so I gave up.

I would be genuinely interested in details about those errors, since that cross-compiler how-to stems from my own OS project - and I haven't encountered any problems on the three systems I did build this environment on. If you could supply a dump of the compiler output (e.g. per mail to mailto:[email protected]), that would be of great help for me.

In case you used a 3.2 GCC, download the 3.3 sources. 3.2 had a bug that introduced the identifier __memcpy, which shouldn't happen. (In case you have to use 3.2, I think I still have the patch lying around somewhere.)

What I'm not sure of is how I'm going to build drivers for my os. I expect that they will be Kernel mode DLLs, I will be using the .drv extension (got the idea for the extension from Win3.1). Anyway I have no idea how I will do that yet.

You might want to look into Project UDI. They define a driver architecture where your OS simply has to provide an environment with the correct services - and any UDI driver could run inside that environment. As of now that covers "only" networking, storage, and USB (beta), but it would be a start. SNAP provides a similar concept for graphics drivers (but the drivers themselves aren't free).

Here is the last few lines and the error message I get BTW I'm using the source from the package downloaded with cygwin

gen-protos: 1346 entries 341 collisions
fix-header: fixing stdlib.h
In file included from ../../gcc-3.3.1-3/gcc/crtstuff.c:62:
../../gcc-3.3.1-3/gcc/tsystem.h:72:19: stdio.h: No such file or directory
../../gcc-3.3.1-3/gcc/tsystem.h:75:23: sys/types.h: No such file or directory
../../gcc-3.3.1-3/gcc/tsystem.h:78:19: errno.h: No such file or directory
../../gcc-3.3.1-3/gcc/tsystem.h:85:20: string.h: No such file or directory
../../gcc-3.3.1-3/gcc/tsystem.h:96:18: time.h: No such file or directory
../../gcc-3.3.1-3/gcc/crtstuff.c: In function `__do_global_dtors_aux':
../../gcc-3.3.1-3/gcc/crtstuff.c:282: warning: passing arg 1 of `__deregister_fr
ame_info' discards qualifiers from pointer target type
../../gcc-3.3.1-3/gcc/crtstuff.c: In function `frame_dummy':
../../gcc-3.3.1-3/gcc/crtstuff.c:318: warning: passing arg 1 of `__register_fram
e_info' discards qualifiers from pointer target type
make[1]: *** [crtbegin.o] Error 1
make: *** [all-gcc] Error 2

hmm Up till now I have been trying to print my letter K using a pointer that was declared in the main function, and it worked

Now, If I make that pointer a global variable, or I make a global variable holding the value of K and then pass that to the pointer, I get nothing.

Is there I havn't setup correctly, as I can't seem to reference global variables.