MIPS Cross compilation -ffreestanding option

[Anitha Boyapati]

Hi,
                                                                                
I am seeing the difference between using hosted environment and a free
standing environment in the startup code with a mips-cross-compiler using 
a dummy main file.
(Compiler built for target MIPS32. --target=mips-elf
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib
--host=i686-pc-linux-gnu)
                                                                                
                                                                                
# File : main.c
                                                                                
int main() { }

mips-elf-gcc -ffreestanding main.c -o main
                                                                                
I have built the main file with -ffreestanding option and checked the
disassembly with mips-elf-objdump. So the dump will have mostly startup
code.
                                                                                
I find that get_mem_info jumps to a certain address which is not in the
code space of the 'main' executable. A series of other library calls also
jump to that address PATTERN (0xbfc00000 + <offset>). I am reading out
part of disassembly of the main program:

a002006c <zerobss>:
a002006c:       3c02a002        lui     v0,0xa002
a0020070:       2442612c        addiu   v0,v0,24876
a0020074:       3c03a002        lui     v1,0xa002
a0020078:       246362d0        addiu   v1,v1,25296
a002007c:       ac400000        sw      zero,0(v0)
a0020080:       0043082b        sltu    at,v0,v1
a0020084:       1420fffd        bnez    at,a002007c <zerobss+0x10>
a0020088:       24420004        addiu   v0,v0,4
a002008c:       3c08a002        lui     t0,0xa002
a0020090:       250861d0        addiu   t0,t0,25040
a0020094:       251d0100        addiu   sp,t0,256
a0020098:       3c04a002        lui     a0,0xa002
a002009c:       248461c0        addiu   a0,a0,25024
a00200a0:       0c00940d        jal     a0025034 <get_mem_info>
................

a0024fc4 <read>:
a0024fc4:       3c02bfc0        lui     v0,0xbfc0 ============???
a0024fc8:       34420038        ori     v0,v0,0x38
a0024fcc:       00400008        jr      v0
a0024fd0:       00000000        nop
                                                                                
a0024fd4 <write>:
a0024fd4:       3c02bfc0        lui     v0,0xbfc0 =========== ???
a0024fd8:       34420040        ori     v0,v0,0x40
a0024fdc:       00400008        jr      v0
a0024fe0:       00000000        nop
                                                                                
a0024fe4 <close>:
a0024fe4:       3c02bfc0        lui     v0,0xbfc0 ========== ???
a0024fe8:       34420050        ori     v0,v0,0x50
a0024fec:       00400008        jr      v0
a0024ff0:       00000000        nop
.................

a0025034 <get_mem_info>:
a0025034:       3c02bfc0        lui     v0,0xbfc0========= ???
a0025038:       344201b8        ori     v0,v0,0x1b8
a002503c:       00400008        jr      v0
a0025040:       00000000        nop

As can be seen, few of the library calls are doing a jump. I would like to 
know 2 issues regarding this:

 [1]. What those address are likely to represent ? Some system call 
      table...of OS ?
 [2]. From info gcc:
	`-ffreestanding'
     Assert that compilation takes place in a freestanding environment.
     This implies `-fno-builtin'.  A freestanding environment is one
     in which the standard library may not exist, and program startup
     may not necessarily be at `main'.  The most obvious example is an
     OS kernel.  This is equivalent to `-fno-hosted'.

     But OS specific routines still seem to be called. I think this is 
because newlib is built with -ffreestanding option. Am I on track ?
(Attached is the full dump output).

I have already posted this on gcc-help. Looks like that is not correct. 
Please redirect me if this is not correct.

Thanks

-- 
Regards,
Anitha B
@S A N K H Y A