OSDev.org

https://github.com/ackOS-project/dev

A recently ported my OS to x86_64. I added serial COM port logging. The problem is this code works and prints "Hello world" to the terminal but this doesn't: it compiles but doesn't print "Hello world!"

The source code for serial_write

1. Just saying "it doesn't work" isn't very helpful. What happens; what output do you get?

2. Almost certainly the fault lies in your strlen() function, but you don't give us the code for it so who knows.

3. What happens if you doDoes that print correctly?

iansjack wrote:1. Just saying "it doesn't work" isn't very helpful. What happens; what output do you get?

2. Almost certainly the fault lies in your strlen() function, but you don't give us the code for it so who knows.

3. What happens if you do

Code: Select all

serial_write(COM1, "Hello world!", 12);

Does that print correctly?

it does not print anything at all even with serial_write(COM1, "Hello world!", 12).

size_t is unsigned it cannot be less than 0

Maybe something weird happens at the function call, maybe because of the flags used for the compilation or linking (telling the way how the function call ABI is done). Just a rough guess, because your code looks correct, at least to me.

And is the function in the same object or source-code file as the code calling it?

EDIT: I found the link to your OS and looked at the linker script: You don't link the data!!!

Greetings
Peter

I'm getting major deja vu here. Problems with strings are typically caused by

1. Not loading enough sectors, so the kernel image in memory is incomplete.
2. Not linking in the .rodata section, so the string is not part of the kernel image.

Try these two hints first.

This is definitely a FAQ. I actually had to check the date to be sure that this was a new thread and not someone committing thread necromancy.

The Wiki does cover this, and even has a redirect of the phrase 'Strings do not work' which brings up the page on Bran's Tutorial's known bugs. It seems that it isn't the easiest answer for newcomers to find despite this. This may need to be addressed, as it will keep happening otherwise, though I am not certain how we could go about it. Any thoughts?

In this case, the focus on the for() loop rather than the string data seems to have been a stumbling block. XY problems happen, I guess.

It's pretty interesting that you're able to get this far running 64-bit code in 32-bit mode.

Schol-R-LEA wrote:This is definitely a FAQ. I actually had to check the date to be sure that this was a new thread and not someone committing thread necromancy.

The Wiki does cover this, and even has a redirect of the phrase 'Strings do not work' which brings up the page on Bran's Tutorial's known bugs. It seems that it isn't the easiest answer for newcomers to find despite this. This may need to be addressed, as it will keep happening otherwise, though I am not certain how we could go about it. Any thoughts?

In this case, the focus on the for() loop rather than the string data seems to have been a stumbling block. XY problems happen, I guess.

1.) Sorry that I didn't point the asking person to the FAQ. In the future I'll try to (mentally and reading) check first if a question can be answered by the FAQ or maybe the Wiki in general or old forum threads.

2.) And yes, it was an XY problem, a linking problem "in disguise" as a loop problem.

3.) Someone already made a redirection for the string-page to the page with the tutorial-error-page. That looks good.

4.) I think the FAQ should be linked in big, fat letters from the forum's top (like the Wiki in general is done). And I don't mean the forum FAQ but the Wiki FAQ!

Greetings
Peter

PeterX wrote:EDIT: I found the link to your OS and looked at the linker script: You don't link the data!!!

Unless the linker script explicitly DISCARDs the sections or he uses some tool like objcopy to remove sections then the `.rodata` section will be emitted but not necessarily in a place they might expect. In this case though the data is in the executable. The problem is as Octocontrabass points out - they are running 64-bit code in 32-bit protected mode and the instructions being run aren't producing the desired results for obvious reasons. Most people often see this issue when displaying to the console (often characters get displayed but not correctly) but this person is seeing it as a result of a function that displays a string to the serial port.

catOS needs to put the processor in 64-bit long mode for this code to work.

MichaelPetch wrote:Unless the linker script explicitly DISCARDs the sections or he uses some tool like objcopy to remove sections then the `.rodata` section will be emitted but not necessarily in a place they might expect. In this case though the data is in the executable..

Thanks for the correction. Didn't know that.

Greetings
Peter

MichaelPetch wrote: catOS needs to put the processor in 64-bit long mode for this code to work.

how do I setup long mode?

There is a decent overview for setting up long mode on the wiki. (Don't forget to check the links at the bottom of the page.)

You should also check the Intel and AMD architecture manuals for details.