Problem with memory allocation in C

[Zottur Zibop]

I have implement my bootloader and then decide to implement a simple kernel just writes classical world message on screen. But I havent implement my memory manager functions such as malloc.., yet.

Here is my main:

char Message1[] = "Hello World";

void main()
{
clrscr();
gotoxy(10, 5);
print(Message1);

while(1);
}

But, although Im sure that my print function works well, it prints nonsense characters on screen. May I have to implement my memory allocation functions and use pointers and allocate memory for them? (Im using gcc)

[distantvoices]

how does the declaration of your print-function look like?

Are you sure you pass the correct parameters to your print-function? Usually, printf (as I know it), expects one string literal and a parameterlist of variable length. (p.ex. printf("amount: %d, lot: %d, dest: %s",amount,lot,dest);)

stay safe...

[Zottur Zibop]

:)No. My print function is so simple...

void print(const char *message)
{
unsigned short offset;
unsigned long i;
unsigned char *vidmem = (unsigned char *)0xB8000;

offset = GetCursorPos();

vidmem += offset*2;// Start at cursor position

i = 0;
while (message != 0) {
*vidmem = message[i++];
vidmem += 2;
}


// Set new cursor position
offset += i;
out(0x3D5, (unsigned char)(offset));
out(0x3D4, 14);
out(0x3D5, (unsigned char)(offset >> );
}

[Whatever5k]

Where do you set the colour attribute?

[Zottur Zibop]

No color attr exists. It uses ex attribute for a cell.So I increment video memory by 2;

while (message != 0) {
*vidmem = message[i++];
vidmem += 2;
}

And also my code works if I change it just like in XOS, by using a pointer (not memory allocated).

const char *Message1;

void main()
{
clrscr();
gotoxy(10, 5);
print(Message1);

for(;;);
}

const char *Message1 = "Deneme";

[Whatever5k]

You *have* to set a colour attribute. Change your code to

Code: Select all

while (message[i] != 0) {
   *vidmem = message[i++];
   *(vidmem + 1) = 0x07;
   vidmem += 2;
}

[Pype.Clicker]

i would suggest you to get a look at your binary file and make sure the "Hello World" string hasn't been dropped due to a bad link script (i.e. strings kernel.bin if you're under linux)

It's very likely that you're missing .rodata or something alike when creating your final kernel binary. Omitting character attributes may lead to no display (if the older attribute was 00 (black on black)), but not in garbage display.

[Zottur Zibop]

.rodata?? I used to use tcc,tlink,tasm before. Im new to gcc, ld and nasm. If someone help if it is a parameter(.rodata), Ill be happy.(ld dont have help)

ld -e _main -Ttext 0x1000 -o kernel.o main.o video.o ports.o string.o
ld -i -e _main -Ttext 0x1000 -o kernel.o main.o video.o ports.o string.o

[Whatever5k]

Pype was suggesting to use a linker script. Try following to link to ELF:

linker.ld:

Code: Select all

OUTPUT_FORMAT("elf32-i386")
ENTRY(_main)

phys = 0x100000;
SECTIONS
{
  . = phys;
  .text : 
  {
    *(.text)
  }
  .rodata :
  {
    *(.rodata)
  }
  .data :
  {
    *(.data)
  }
  .bss :
  {
    bss = .;
    *(COMMON)
    *(.bss)
  }
  kernel_end = .;
}

Now do:
ld -T linker.ld -o your_kernel kernel.o main.o video.o ports.o string.o

Btw, did you try the colour attribute thing?

[Zottur Zibop]

ables I use your script. But it gives an error:

target elf32-i386 not found

I comment out that line and than it links well. But main problem still remains. :-\

The code below works well.

const char *Message;
void main()
{

clrscr();
gotoxy(10, 5);

print(Message);

for(;;);
}

const char *Message="Deneme";

But the code below :

const char Message[6] = "Deneme";

void main()
{

clrscr();
gotoxy(10, 5);

print(Message);

for(;;);
}

gives this error in Bochs:

Event type: PANIC
Device: [FDD ]
Message: io read from address 000003f2, len=4

I still reading linker script tut, but any help will be appreciated..) Thanks..

[Pype.Clicker]

ables I use your script. But it gives an error:

target elf32-i386 not found

so your compiler don't support for ELF, which makes the link script unappropriated as COFF doesn't support .rodata and put strings in .text section.

i don't know how you get your kernel loaded, but one thing is sure : if you just assume it starts at address 0 (**hack**), having the string first will make the string executed, which is unlikely to work well ...

"but what ? i said entry = _main" will you say.
true. Which makes the COFF file store this information, but if you don't use it to jump to CODESELECTOR:_main rather than CODESELECTOR:<start_of_kernel_image>, it's pretty useless ...

[Zottur Zibop]

Pype, Im using last version of Nasm.doesnt it support elf format??(I dont know)
And you are right. I start at addr 0 of my kernel and as I thought and you said, it execute the string first. What Im trying to do is to prevent this.
By the way, I think the problem is not using an asm entry for my kernel. (My kernel is completely written in C). And if I dont remember wrong, I read an article which advises to code an asm-kernel first and than jmp to c kernel. I think I can overcome my problem by an asm-kernel jmping to c-kernel...Ill try....

[Pype.Clicker]

NASM supports for ELF since a long time ago ... i dunno why you talk about nasm, anyway. You're facing a *linking* problem: the linker doesn't recognize ELF output format. nasm has nothing to do with this ...

[Unexpected]

Which format is better to use?
A.OUT, ELF, COFF ?

[Pype.Clicker]

there's no "absolute best format". Both have pros and cons, but as ELF is now supported by DJGPP and CYGWIN (through optionnal binaries or objcopy) while there's no COFF support for Linux (afaik), using ELF is probably more portable, and will open you the gates of GRUB.

The only thing i would not recommend is A.OUT -- iirc, it has no dynamic shared libraries support -- except for very early stages (for instance, your kernel would nicely fit an a.out that could easily be loaded by a small bootloader