Issues with pointers

[abstractmath]

I recently started working on a 64-bit os, and I'm getting some strange behavior with pointers. I have this C code:

Code: Select all

#include "../lib/typeout.h"

void main(){
    char testStr[15] = "Hello, World!\n\0";
    char* testStr2 =   "Hello, World!\n\0";
    screen_clear();
    screen_print_str(testStr);//Works perfectly, prints "Hello, World!" on the screen
    screen_print_str(testStr2);//Prints garbage

    while(1){}
    return;
}

I believe this could be an issue with the Linker script I'm using, from past experience. Also, another interesting piece of the puzzle is that upon looking at the hexdump of the binary file I'm generating, this can be found

Code: Select all

00000410  83 ec 20 48 b8 48 65 6c  6c 6f 2c 20 57 48 89 45  |.. H.Hello, WH.E|
00000420  e9 c7 45 f1 6f 72 6c 64  66 c7 45 f5 21 0a c6 45  |..E.orldf.E.!..E|

Notice how it seems as though the "Hello, World!" message seems to be rather disjointed, and I believe this is around where my char pointer is pointing to. Also, later on in the hexdump, this can be seen as well:

Code: Select all

00000770  45 fc 8b 45 f8 0f b7 55  fc ef 90 5d c3 48 65 6c  |E..E...U...].Hel|
00000780  6c 6f 2c 20 57 6f 72 6c  64 21 0a 00 00 66 2e 0f  |lo, World!...f..|

And here, the message is in a continuous piece of memory, as one would have expected. Also, one last piece of information is that the linker script I'm using is pulled from an earlier 32-bit OS I was working on, and is now being used in this 64 bit OS project. I'm not sure if that actually makes any difference, however. Again, I suspect that this is an issue with the linker script, but I'm not sure and I'd love some help to debug. Thanks in advance!

[Octocontrabass]

I believe this could be an issue with the Linker script I'm using, from past experience.

Why not show your linker script if you think it might be the problem?

Also, another interesting piece of the puzzle is that upon looking at the hexdump of the binary file I'm generating, this can be found

[...]

Notice how it seems as though the "Hello, World!" message seems to be rather disjointed, and I believe this is around where my char pointer is pointing to.

This is the code to initialize the array you've declared within the function. It appears disjointed because it's code and not data, but you can still see parts of the string because the instructions contain pieces of the string as their operands.

Also, later on in the hexdump, this can be seen as well:
[...]
And here, the message is in a continuous piece of memory, as one would have expected.

But it's right between pieces of code, which is not what I would expect from a typical linker script.

[abstractmath]

Ah yes, sorry I forgot to post my linker script.

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
phys = 0x00010000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

[Octocontrabass]

Since it's a flat binary, there's nothing to tell your loader where in memory it wants to be while it's running. Are you loading the binary at the address indicated in your linker script?

I don't think it's the problem here, but your linker script might miss some sections since you're not using wildcards in your section names.

[MichaelPetch]

Octo is correct about the one that appears to be broken up being code (to build the string on the stack inside the function that declares the string to be a local character array). Part of that snippet of data/code translates to:

Code: Select all

00000003  48B848656C6C6F2C  mov rax,0x57202c6f6c6c65482057
0000000D  488945E9          mov [rbp-0x17],rax

. Since the data that doesn't seem to print properly is a string literal in the `.rodata` section I think a couple of things could cause this. You either loaded the code and data to the wrong memory location or you didn't read enough sectors into memory to load your entire kernel. I assume since you set the linker script to a starting VMA of `phys = 0x00010000;` that you actually loaded the code to physical address 0x10000. I also assume that you have actually entered 64-bit long mode and that this code isn't executing in 32-bit protected mode?

[abstractmath]

I went ahead and changed the phys variable to the location where I'm loading the kernel, and that seems to have fixed the problem.