OSDev.org

hello everybody,
i have written simple kernel which print hello word,
but when i trying to access global variable ( like i declare videomem which access video memory in my 'c' file kernel.c) it cant work, but when i put local in function it work properly.

my second problem is
i cant set gdt data section
In my init.s
;mov eax, gdt_data
      ;mov ds, eax
      ;mov es, eax
      ;mov fs, eax
      ;mov gs, eax
      ;mov ss, eax

my gdt data section not set to other data register
check in my source & try removing comment.

when i comment out simillar above move data section part and i declare variable local, it work properly and display "hello"
i use grub as boot loader...
any body know what grub set gdt to data and code initially?
please help me, i dont understand why my data section set

i put my source code please check it
waiting for reply


thnx
nil

[attachment deleted by admin]

let me try to summarize your memory design ... i'm not sure to have it correct and it seems quite ... personnal a small .nfo file about that in future .zips (for example as part of your OSID would have be nice.

- you use grub for loading
- your kernel is split in 3 sections (.text, .data and .bss) which are to be loaded at 1MB, 2MB and 3MB respectively (physical addresses, i mean)
- you expect the kernel to run in "high end" of the memory, so you wish to have it at logical offset 0xC000000, 0xC020000, 0xc030000 and will as a first step toy with base of segments in early assembly stuff in init.s when you reload the GDT.

One thing that looks weirds to me is that while the .data is physically distant from 1MB to .text, you plan a logical address distant from 2MB !? maybe it's by design but i think things would be easier for you if you used 0xC010000 and 0xC020000 for .data and .bss

Also, you should know that GRUB will not perform any paging and magistrally ignores any 'virtual addresses' you provided to the linker while the linker *will* issue offsets for those virtual addresses.

If you want 1MB (physical) to be appearing as offset 0xC00000 in the code segment, you should have gdt_code.base = (0x00100000 - 0xc0000000) so that the linear address computed by the cpu will be 0xC000wxyz + (0x00100000 - 0xC0000000) = 0x0010wxyz as expected.

hi pype.clicker,
i dont understand what u want to suggest me ??? ,
but can u try to access global variable from my source code,
is it require to change in gdt setting (stack or bss) so that i can access it properly...
and i also tell about my second problem that data section not properly set...
do u find any problem in my code which i already send u
please reply me,
???

thanx
nil

nil wrote: hi pype.clicker,
i dont understand what u want to suggest me

I don't understand very well what you're trying to do and trying to say either, so we're even ... Maybe if your member profile included information about your native language someone else could try to translate or explain you through private messages.

I'll try to be more 'direct'-styled. Sorry if that sounds rude. I hope it'll be easier to decode for you

is it require to change in gdt setting (stack or bss) so that i can
access it properly...

Imho,

• Forget about ': AT(0x200000)' and ': AT(0x300000)' in your linker script. Just keep

  Code: Select all

     .text virt : AT(phys)
        {
           code = .;
           *(.text)
                          *(.rodata)
        }
        .data (0xc0200000) : 
        {
           data = .;
           *(.data)
        }
        .bss : 
        {
           bss = .;
           *(.bss)
           *(COMMON)
        }
        end = .;
  

  as your 'sections' block.
• The information about GRUB's GDT are in Multiboot Standard. Make sure you read http://www.osdev.org/osfaq2/index.php/BareBones and http://www.osdev.org/osfaq2/index.php/GRUB
• Pick up a paper and *draw* what you wish to have. Make sure it's clear to you and then if possible attach a scan/ascii art of what you plan to do
• Your linker produced an ELF that can run at 0xC000_0000 *and only there*. As you cannot load it there (lack of phys memory), you must use some MMU technique so that physical address 0x0010_0000 appears at logical offset 0xC000_0000.
  This means that GDT_CODE must have base=0x4010_0000. Check your undocumented bit constants to make sure it's the case.

please reply me,
???

thanx
nil

I *really* think you should run your code in a debugger-enabled version of *BOCHS* step by step and check with cpu-status-dumping commands that your code is loading registers as expected. And no, sorry, i cannot do that for you.