C and variables

[Vladaz]

Hello,
I have some problems. If I declare variables outside function like this:

#include "smth.h"
unsigned char buf = 1;

, then when i get to function, the value of that variable buf becomes 0(null) in that function.
Can someone help me, please?

[Solar]

No, the value of that variable does not become null; you're either doing something wrong or working with faulty assumptions.

* Did you by chance re-declare the variable?

* If using a custom linker script, did you by chance forget to link the respective data segment into the executable?

Please give the function code and the respective command lines you used to compile / link the code.

[Vladaz]

My linker:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(kernelstart)
SECTIONS
{
.text 0x8600 : {
  *(.text)
  }
  .data : {
    *(.data)
  }
  .bss :  {                
    *(.bss)
  }
}

Is it wrong?


There's my vesa code - http://193.219.53.186/vladas/vesa.c

[Solar]

Try this:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(kernelstart)
SECTIONS
{
.text 0x8600 : {
  *(.text)
  *(.rodata)
  }
  .data : {
    *(.data)
  }
  .bss :  {   
    *(COMMON)             
    *(.bss)
  }
}

That's adding .rodata and COMMON, as described in the OS FAQ / BareBones. I give it a 98% chance of solving your problem.

[Vladaz]

It still doesn't work.
There's my full OS code with bootloader, kernel and build.bat -
http://193.219.53.186/vladas/vospow.zip

I will be very thankful if you will help me.
Thanks in advance.

[sparkvolt]

Been readin this forums for quite a while but never posted anything so before replying to you I'll say Hi to all the gurus and wizards here . Now to your problem.
I had very same problem with my kernel's C side of code. Referencing global variables would always return 0. Assigning some value to them would give them value I just assigned. I used multiboot with GRUB and couldnt quite put my finger on the source of problem. Problem turned out to be that .data section of my kernel was not being loaded into memory by grub. I am assuming your boot loader may be doing the same thing. My problem was that I defined .data section in assembly part of kernel and was using that in a.out kludge header. Then after poking around the code and my linker scripts I realized Im doing it wrong. I added _edata and _sdata symbols at the begining and the end of my data section and used _edata in a.out kludge header. As it turned out, my global vars became available. Your problem could probably be that you are not loading the .data section of your kernel properly or at all. Use bochsdebug and examine memory where your global variables are supposed to reside. I did this and guess what I saw. 00000000. I also tried other offsets just in case to see if .data section may be misaligned or loaded somewhere else. Hope this helps you out or at least points you in right direction.

[Ytinasni]

I would try

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(kernelstart)
SECTIONS
{
.text 0x8600 : {
  *(.text)
  . = ALIGN(16);
  *(.rodata)
  }
  . = ALIGN(16);
  .data : {
    *(.data)
  }
  . = ALIGN(16);
  .bss :  {   
    *(COMMON)             
    . = ALIGN(16);
    *(.bss)
  }
}

edit: And posting your code on a server that doesnt exist/we cant access doesnt help much.

[Vladaz]

sparkvolt: I didn't understood what I have to do.
Ytinasni: With that code it still doesn't work

Can you maybe download that code that i posted URL.
http://193.219.53.186/vladas/vospow.zip

Because I'm too lame to find that bug

[Ytinasni]

your bug is not in your C code. it is in your bootsector.
Your kernel is being loaded to 0x8800 (how? i dont know!!!! but the bochs debugger never lies....) which is why your variable appears to have a wrong value.

I cant see how you load it there, though. You definately call int13h with es:bx = 0:0x8600, and your protected mode bases and limits are 0 and 2[sup]32[/sup]-1

I'm gonna have to admit i have no clue

[Vladaz]

Thank you very much! I changed my address where kernel must to be loaded to 0x8400 and now it works

[Solar]

Uh...

If your bootloader doesn't load your kernel to the address it's told to, that's a bug. Just giving it the wrong address to it loads the kernel to the "right" address only fixes the symptom, not the cause.

In the very least, that's the next bug you should be hunting down. Your bootloader / global variable problem has been worked around, not fixed...

[Candy]

my guess is that you load a sector too much, either the boot sector again (for a binary loader) or an unknown fat entry (say, the null entry, and then the rest of the chain, for a fat loader). You might also have some more complex error, but I don't have the time to read the code.