OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:27 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Sun May 24, 2020 9:12 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
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:
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
Quote:
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?


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Sun May 24, 2020 11:01 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
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.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Sun May 24, 2020 11:01 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
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.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Mon May 25, 2020 3:22 am 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
I actually can't find the string content in the binary file, the link command I used is


Code:
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?


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Mon May 25, 2020 6:26 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
Here is a quick update on my new but still ineffective ld command

Code:
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


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Mon May 25, 2020 8:59 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
Another thought as nullplan suggested, how to include a string literal as part of text? I am
all ears!!!


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 5:16 am 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5100
Try using a linker script. Here is one that should be easy to modify for your needs.


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 6:00 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
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:
#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.


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 6:27 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
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).


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 9:06 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
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:
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_html/1.-Environment%20setup.html


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 9:18 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
Quote:
ENTRY(start)
SECTIONS
{
.text 0x100000 :
{
code = .; _code = .; __code = .;
*(.text)
*(.rodata)
. = ALIGN(4096);
}


Top
 Profile  
 
 Post subject: Re: string literal issues with gcc -ffreestanding -fno-pie
PostPosted: Tue May 26, 2020 9:44 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 81 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group