Bona Fide OS Developer
View unanswered posts | View active topics It is currently Thu Mar 28, 2024 2:25 pm



Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2, 3  Next
 problem with char* 
Author Message

Joined: Wed Feb 10, 2010 6:32 am
Posts: 26
Post Re: problem with char*
first of all, thanks for taking that much time ^^

when I try puts("blub\0 something");
everything after \0 is not displayed.
and the length function works fine, I tested and printed the result many times.

I think it must be gcc because of the output size when I forget the \0 even at one place in my kernel it gets 1.1MB big
otherwise it is only 16k in size.

I thought it might be one of the compiler options...
well maybe I just might to live with it =)

maybe I simply autoreplace every ") with \0") in my code xD


Fri Feb 12, 2010 10:36 am
Profile

Joined: Tue Jul 28, 2009 4:09 am
Posts: 58
Location: United Kingdom
Post Re: problem with char*
Hey,

Is the file size difference the only noticeable issue? I got the impression that there was some functional problem; such as the printing of a string far longer than the one specified?

If the only problem is size, there's little I can see from the code, but I would go through the GCC manual looking for optimizations related to strings, and also use objdump (or readelf if appropriate) to see what is different about the file structure. If anything of note comes up, please ask about it, I am intrigued.

Thanks,

James


Sun Feb 14, 2010 4:59 am
Profile

Joined: Wed Feb 10, 2010 6:32 am
Posts: 26
Post Re: problem with char*
no it's not only size.. the whole kernel won't boot...


Sun Feb 14, 2010 10:29 am
Profile

Joined: Tue Jul 28, 2009 4:09 am
Posts: 58
Location: United Kingdom
Post Re: problem with char*
Hey,

Does it not boot when compiled with no optimisations? Are there any obvious differences in the output of objdump for the Regular, and "\0" appended outputs?

What results do you see when stepping through the code in a debugging emulator, like Bochs. Does the kernel code even begin to get run?

Also, how is the kernel booted? Is it a pure Binary File loaded by GRUB?

Thanks,

James


Sun Feb 14, 2010 11:20 am
Profile

Joined: Wed Feb 10, 2010 6:32 am
Posts: 26
Post Re: problem with char*
This is the working Version:
kernel.o: file format elf32-i386

Contents of section .text:
0000 83ec1ce8 fcffffff c7042400 000000e8 ..........$.....
0010 fcffffff ebfe ......
Contents of section .rodata:
0000 48616c6c 6f200020 556e7369 63687462 Hallo . Unsichtb
0010 617200 ar.
Contents of section .comment:
0000 00474343 3a202847 4e552920 342e342e .GCC: (GNU) 4.4.
0010 3300

and this doesn't work

kernel.o: file format elf32-i386

Contents of section .text:
0000 83ec1ce8 fcffffff c7042400 000000e8 ..........$.....
0010 fcffffff ebfe ......
Contents of section .rodata.str1.1:
0000 48616c6c 6f20556e 73696368 74626172 Hallo Unsichtbar
0010 00 .
Contents of section .comment:
0000 00474343 3a202847 4e552920 342e342e .GCC: (GNU) 4.4.
0010 3300

I used objdump -s ...

it is loaded by grub, and the Big kernel gets me: Error 13: Invalid or unsupported executable format

I uploaded my little project ... cause I really can't find anything :D http://cryff.net/clean.tar.gz
could you take a peek?

Bochs won't work for me cause I am working on the cli and bochs doesn't have a curses mode...


Mon Feb 15, 2010 3:59 am
Profile

Joined: Sat Jul 25, 2009 9:15 am
Posts: 257
Post Re: problem with char*
here is a quicky & try again... remove optimization in gcc replace -O with -O0... and could you do a quick explain of what the other options do...


Mon Feb 15, 2010 9:48 am
Profile

Joined: Wed Feb 10, 2010 6:32 am
Posts: 26
Post Re: problem with char*
THANK YOU!! wow finally

who would've thought gcc simply optimises the \0 away... finally it works ! I only changed the -O to -O0 and kept all the other flags...

you can get a list of the flags here: http://gcc.gnu.org/onlinedocs/gcc-4.4.1 ... tions.html

thanks again! finally no pesky \0 anymore ^^


Mon Feb 15, 2010 10:57 am
Profile

Joined: Tue Jul 28, 2009 4:09 am
Posts: 58
Location: United Kingdom
Post Re: problem with char*
Hey,

I thought it might be an optimization thing (as I said above :P) You don't intend to leave the code without optimization do you? Or has understanding this made it possible to run your kernel with optimizations on?

Thanks,

James


Mon Feb 15, 2010 11:25 am
Profile

Joined: Wed Feb 10, 2010 6:32 am
Posts: 26
Post Re: problem with char*
hi!

well, actually I leave it without optimization for now..
this hold me back for such a long time and I don't want to deal with it anymore .)

I wanna come to the interesting topics soon and optimization is not important to me for now ^^

protected mode kills me xD

but thanks for the effort... really appreciate it !


Mon Feb 15, 2010 12:18 pm
Profile

Joined: Tue Jul 28, 2009 4:09 am
Posts: 58
Location: United Kingdom
Post Re: problem with char*
Hey,

Well I will have a look at your code later, and see if I come up with anything anyway. Optimization failing is a sign of a fault in code, not the compiler. I am however glad it worked.

I made a post recently (http://forums.osdever.net/viewtopic.php?f=5&t=172) which basically says, if you want to understand protected mode, read the manual. The Intel IA-32 Processor Manuals describe the process step by step, and will help you understand exactly what is involved. There are also numerous tutorials on this site, which are easy to use, once you understand the theory.

Good Luck!

Thanks,

James


Mon Feb 15, 2010 12:23 pm
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2, 3  Next


Who is online

Users browsing this forum: No registered users and 18 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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin and tweaked by the BF Team.