OSDev.org

I try to pass char* to function.

put_c just prints a char on screen.

When i execute code, instead of printing 'H' i get nothing on screen.

dump of obj


How to fix if?

UPD: with it works correctly, but i don't know why with i got a fault.

The problem might well be in put_c(), but we don't get to see that function.

No, when i pass char directly to put_c() it works correctly.

Depending on the compiler, the code you have assigns the pointer 'str' to a const string of "Hello world" that probably is in a different "segment" than your DS points to. i.e.: The compiler may treat the following

a bit different than:

The first may place a pointer relative to the BSS section (or CONST or whatever section) where the second may place a pointer relative to the current stack pointer and use the SS segment.

Unless you know what compiler you are using and what it will do with it, it is not wise to use:

in OS/firmware/driver/etc development.

Could it be that your DS != SS or the compiler placed the string at the end of your code?

Ben
- http://www.fysnet.net/osdesign_book_series.htm

"Hello world" is located in rodata


UPD: Flags that i use with gcc: -m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector -nostartfiles -nodefaultlibs

I'd bet that you have a custom bootloader that isn't reading enough sectors (your kernel) into memory and the string you want to print is not physically loaded into memory. It would work for stack based string because the string is likely placed directly on the stack programmatically by the compiler (the actual method used is compiler/compiler option dependent).

I'm making this guess (without even seeing how the kernel was loaded) based on the fact I have seen very similar questions with nearly the identical behaviour.

The bootloader loads enough sectors into memory.

Problem is that the code generated by compiler doesn't try pass any a pointer to function.

Yes it does. It just so happens that the data is the first data in the rodata section, so it has an offset of 0x00000000.


Here is the code:

The compiler reserved a pointer-sized variable at [ebp-12] (which is on the stack) and placed the offset from the .rodata section to the string. It then retrieves this value, pushing it onto the stack and calling the print_s routine:

The above could be see as (in Intel syntax), though the above code eliminates the need for the stack clean up:

You will need to find out where your rodata section is, related to the text section and make an adjustment. For example, if your rodata section is 0x100 bytes from the "start of the file", then you will need.

However, this isn't really the correct way to do it either.

My suggestion, to make it all must easier, is to only have one section. However, this gets difficult the larger the code base.

I don't use GCC so someone else is going to have to tell you how to get it to create only one section, or tell you how to output the correct binary file.

I use a standard Windows PE file with, what would be considered, a single section, so that SS == DS == ES, etc.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

How to fix it?
+ i give my link.ld - https://pastebin.com/Z7ftgcwV
and make file - https://pastebin.com/VgDnxfCW

You keep dumping the output of the object files. I'm curious, are you converting object files directly to binary and putting that on your disk? I hope not. You need to link to an executable and have that output to binary. If you showed us the commands you use to compile/assemble and link (and any linker script) we might get a better understanding of what is going on. It seems like your kernel isn't using fully resolved addresses and the only way I can see that happening is if you aren't properly linking to a fully resolved binary executable and you are writing binary forms of object files directly instead.

It's happening(not passing a pointer), because i compile with -c flag, without -c occur linking with data from .rodata and a pointer is passed, but with it a comliper try linking with CRT that isn't needed.

p.s i left links to link.ld and Makefile files above.

Well I see issues in your make file and possibly your linker script. What I first need to know is... where is your bootloader loading the kernel into memory at? Your make file suggests that it may be at 0x1000 in memory but the linker script you are using specifies 0x100000.

0x1000, i fixed link.ld.

UPD. it already works Thank everybody.

Although you say you got it working, I'll present the minimum changes I would have made. In the linker script the origin point initial VMA should be 0x1000. I'd also use the linker script to force the text section of kernel/kernel.o to always be the first file (then you can drop the explicit use of it from the make rule that generates the ELF file). In the make file I'm inclined to convert the kernel.elf to kernel.bin with OBJCOPY. kernel.bin should be built from kernel.elf not kernel.o. If you aren't using a cross compiler (and I highly recommend you use a cross compiler) I'd seriously consider compiling with the option -fno-PIC to avoid generating the global offset table and position independent code that relies on it. I changed Makefile to: and link.ld to: It should be noted that your kernel.c should contain only a single function - your kernel entry point. Placing any other functions in that file could have any one of the functions become the entry point. You can avoid all this by placing the kernel entry point function into its own special section (like .text.entry) and ensure that section comes before all others (in the linker script). If you did it this way link.ld could look like: In kernel.c you can now have any number of functions, but your kernel entry point (I'm using kernel_main as an example) could look like: __attribute__ ((section (".text.entry"))) places the kernel_main function into the section .text.entry . The linker script ensures .text.entry section is placed in the output file first. Doing it this way also means that kernel.o doesn't have to be the first object listed when building kernel.elf, nor does it require kernel.o being referenced in the linker script. Your kernel entry point must be the only thing in section .text.entry