string literal issues with gcc -ffreestanding -fno-pie

[ITchimp]

I have trouble declare strings literals in a freestanding environment... (ie. gcc -ffreestanding)...

if I try to define a string literal like what I would do in a hosted environment...

Code: Select all

void main(){

char *message = "this is awesome";
....

does not work at all, I iterate thru each character, but all gets empty content

if I do

void main(){
char message[] = "this is awesome";
....

now it works, I can print it just fine... why the former fails? what is the reason for the failure?
why can't I define string literal and assume it will be reserved in memory as if I do assembly programming directly?

[nullplan]

Likely you don't link in the ".rodata" section, or ".rdata" or whatever it is called in your case. It should be part of the .text section.

[kzinti]

Use objdump and readelf, check your linker script, make sure the string is actually in your binary,

When you use the freestanding option, the linker will not use your host's default script.

[ITchimp]

I actually can't find the string content in the binary file, the link command I used is

Code: Select all

ld -o kernel.bin -Ttext 0x1000 kernel entry.o kernel.o --oformat binary

I can however find the string content in kernel.o in rodata

can someone explain to my what -Ttext 0x1000 is doing here? does that place the text section at 0x1000 of the kernel image? how do I add the rodata to the find binary output?

[ITchimp]

Here is a quick update on my new but still ineffective ld command

Code: Select all

ld -o kernel.bin -Trodata-segment 0x1000 -oformat binary kernel.o kernel_entry.o

still linker does not strip the rodata section and place it at address 0x1000

[ITchimp]

Another thought as nullplan suggested, how to include a string literal as part of text? I am
all ears!!!

[Octocontrabass]

Try using a linker script. Here is one that should be easy to modify for your needs.

[ITchimp]

After using linker script, I was able to find the string literal in my os-image, but the problem is that I still can not use it... after further investigation, I find that in the code below

Code: Select all

#include "../drivers/screen.h"

char* message1="this is awesome2 \n";

void main(){

   .....

the message1 has the value of 0x00000000... it does not point to the location of "this is awesome2 \n" literal at all.

[MichaelPetch]

If you wrote your own bootloader make sure you read enough sectors into memory to get the entire contents of your kernel. If you showed your complete code (bootloader, kernel etc) and how you build it we might be able to help you better. Hopefully when you compile the C files to object files you are using the compile option `-c` to generate ELF objects and not ELF executables (assuming you are not on Windows).

[ITchimp]

In boot loader I read in 16 sectors (16*512 = 8k), so everything is read in...
I have made sure of that...

bootloader is really simple, just call a few real mode bios function to load the os image, then
set up GDT entries (null, code, data) and jump to kernel entry

within kernel entry jump to main function... that is it

so kernel code looks extremely simple

Code: Select all

char* msg2 = "this doesn't work";
void main(){
 // some sample screen refresh print a few string etc...
 char msg[]= "this is awesome\n";
}

msg[] set up on stack works....

msg2 set up in rodata or text has the value of 0x00000000

linker script is the standard one adopted
http://www.jamesmolloy.co.uk/tutorial_h ... setup.html

[ITchimp]

ENTRY(start)
SECTIONS
{
.text 0x100000 :
{
code = .; _code = .; __code = .;
*(.text)
*(.rodata)
. = ALIGN(4096);
}

[MichaelPetch]

Where in physical memory did you load your kernel? If you didn't load it at 0x100000 then it won't work. The value you need to use is the physical address the kernel starts at in memory.