Why is ld complaining?

[NunoLava1998]

Compiling boot.asm with NASM removed the error:

Code: Select all

kernel.o: In function `prints':
kernel.c:(.text+0x15d): undefined reference to `strlen'

Still complaining about strlen.

[Ycep]

If you keep trying to hide your OS that could be written for 5 minutes, for 2 mins if you copy paste meaty skeleton as you did, there's few things I could suspect:

• You did not included apporiate header with prints() definition.
• You did not declared prints() in any header at all.

I defined it in tty.c. It is valid, it is literally tty.c from meaty skeleton with

However, GCC compiled fine with -w. I use -w beacuse some errors in my code are intended and if they aren't GCC will just fix it anyway

terminal_writestring:

Code: Select all

void terminal_writestring(const char* data) {
	terminal_write(data, strlen(data));
}

prints:

Code: Select all

void prints(const char* data) {
	terminal_write(data, strlen(data));
}

Repeating:

• You did not included apporiate header with prints() definition.
• You did not declared prints() in any header at all.

You may defined your function, but did not declared it in any header (.h) .

[NunoLava1998]

If you keep trying to hide your OS that could be written for 5 minutes, for 2 mins if you copy paste meaty skeleton as you did, there's few things I could suspect:

• You did not included apporiate header with prints() definition.
• You did not declared prints() in any header at all.

I defined it in tty.c. It is valid, it is literally tty.c from meaty skeleton with

However, GCC compiled fine with -w. I use -w beacuse some errors in my code are intended and if they aren't GCC will just fix it anyway

terminal_writestring:

Code: Select all

void terminal_writestring(const char* data) {
	terminal_write(data, strlen(data));
}

prints:

Code: Select all

void prints(const char* data) {
	terminal_write(data, strlen(data));
}

Repeating:

• You did not included apporiate header with prints() definition.
• You did not declared prints() in any header at all.

You may defined your function, but did not declared it in any header (.h) .

How do i declare? Does a

Code: Select all

return;

do?


Also i tried to port the strlen and this happened (-w... not even with -Wall or -Wextra)

Code: Select all

In file included from i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\strlen.c:23:0,
                 from include/tty/tty.c:5,
                 from kernel.c:4:
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h: In function '__realpath_chk':
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:22:31: error: unknown type name '__THROW'
         size_t __resolvedlen) __THROW __wur;
                               ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:24:9: error: expected ')' before '(' token
         (const char *__restrict __name,
         ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:27:9: error: expected ')' before '(' token
         (const char *__restrict __name,
         ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:33:1: error: unknown type name '__fortify_function'
 __fortify_function __wur char *
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:33:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
 __fortify_function __wur char *
                          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:50:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__THROW'
        size_t __nreal) __THROW __nonnull ((2));
                        ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:51:47: error: expected ')' before '(' token
 extern int __REDIRECT_NTH (__ptsname_r_alias, (int __fd, char *__buf,
                                               ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:55:7: error: expected ')' before '(' token
       (int __fd, char *__buf, size_t __buflen,
       ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:60:1: error: expected declaration specifiers before '__fortify_function'
 __fortify_function int
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:75:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__THROW'
   __THROW __wur;
   ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:76:44: error: expected ')' before '(' token
 extern int __REDIRECT_NTH (__wctomb_alias, (char *__s, wchar_t __wchar),
                                            ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:79:1: error: unknown type name '__fortify_function'
 __fortify_function __wur int
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:79:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
 __fortify_function __wur int
                          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:97:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__THROW'
          size_t __len, size_t __dstlen) __THROW;
                                         ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:99:10: error: expected ')' before '(' token
          (wchar_t *__restrict __dst,
          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:103:10: error: expected ')' before '(' token
          (wchar_t *__restrict __dst,
          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:109:1: error: unknown type name '__fortify_function'
 __fortify_function size_t
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:110:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__NTH'
 __NTH (mbstowcs (wchar_t *__restrict __dst, const char *__restrict __src,
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:129:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__THROW'
          size_t __len, size_t __dstlen) __THROW;
                                         ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:131:10: error: expected ')' before '(' token
          (char *__restrict __dst,
          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:135:10: error: expected ')' before '(' token
          (char *__restrict __dst,
          ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:140:1: error: unknown type name '__fortify_function'
 __fortify_function size_t
 ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:141:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__NTH'
 __NTH (wcstombs (char *__restrict __dst, const wchar_t *__restrict __src,
 ^
In file included from include/tty/tty.c:5:0,
                 from kernel.c:4:
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\strlen.c:29:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
       const char *str;
       ^
In file included from i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\strlen.c:23:0,
                 from include/tty/tty.c:5,
                 from kernel.c:4:
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\stdlib.h:20:14: error: old-style parameter declarations in prototyped function definition
 extern char *__realpath_chk (const char *__restrict __name,
              ^
In file included from include/tty/tty.c:5:0,
                 from kernel.c:4:
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\strlen.c:34:20: error: 'str' undeclared (first use in this function)
    for (char_ptr = str; ((unsigned long int) char_ptr
                    ^
i:\ghost-i686-elf-tools\lib\gcc\i686-elf\4.8.2\include\strlen.c:34:20: note: each undeclared identifier is reported only once for each function it appears in
In file included from kernel.c:4:0:
include/tty/tty.c: In function 'libc_hidden_builtin_def':
include/tty/tty.c:7:21: error: storage class specified for parameter 'VGA_WIDTH'
 static const size_t VGA_WIDTH = 80;
                     ^
include/tty/tty.c:7:1: error: parameter 'VGA_WIDTH' is initialized
 static const size_t VGA_WIDTH = 80;
 ^
include/tty/tty.c:8:21: error: storage class specified for parameter 'VGA_HEIGHT'
 static const size_t VGA_HEIGHT = 25;
                     ^
include/tty/tty.c:8:1: error: parameter 'VGA_HEIGHT' is initialized
 static const size_t VGA_HEIGHT = 25;
 ^
include/tty/tty.c:9:24: error: storage class specified for parameter 'VGA_MEMORY'
 static uint16_t* const VGA_MEMORY = (uint16_t*) 0xB8000;
                        ^
include/tty/tty.c:9:1: error: parameter 'VGA_MEMORY' is initialized
 static uint16_t* const VGA_MEMORY = (uint16_t*) 0xB8000;
 ^
include/tty/tty.c:11:15: error: storage class specified for parameter 'terminal_row'
 static size_t terminal_row;
               ^
include/tty/tty.c:12:15: error: storage class specified for parameter 'terminal_column'
 static size_t terminal_column;
               ^
include/tty/tty.c:13:16: error: storage class specified for parameter 'terminal_color'
 static uint8_t terminal_color;
                ^
include/tty/tty.c:14:18: error: storage class specified for parameter 'terminal_buffer'
 static uint16_t* terminal_buffer;
                  ^
include/tty/tty.c:16:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void terminal_initialize(void) {
                                ^
include/tty/tty.c:29:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void terminal_setcolor(uint8_t color) {
                                       ^
include/tty/tty.c:33:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void terminal_putentryat(unsigned char c, uint8_t color, size_t x, size_t y) {
                                                                              ^
include/tty/tty.c:38:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void terminal_putchar(char c) {
                               ^
include/tty/tty.c:48:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void terminal_write(const char* data, size_t size) {
                                                    ^
include/tty/tty.c:53:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void prints(const char* data) {
                               ^
In file included from kernel.c:5:0:
include/kbd/kbd.c:9:1: error: parameter 'kbdus' is initialized
 unsigned char kbdus[128] =
 ^
include/kbd/kbd.c:49:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
include/kbd/kbd.c:57:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
include/kbd/kbd.c:65:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
include/kbd/kbd.c:69:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
kernel.c:7:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void kernel_main(void) {
                        ^
kernel.c:16:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 void newlinef123(void){
                       ^
In file included from kernel.c:5:0:
include/kbd/kbd.c:9:15: error: declaration for parameter 'kbdus' but no such parameter
 unsigned char kbdus[128] =
               ^
include/kbd/kbd.c:7:5: error: declaration for parameter 'Key' but no such parameter
 int Key;
     ^
include/kbd/kbd.c:6:5: error: declaration for parameter 'ScanCode' but no such parameter
 int ScanCode;
     ^
In file included from kernel.c:4:0:
include/tty/tty.c:14:18: error: declaration for parameter 'terminal_buffer' but no such parameter
 static uint16_t* terminal_buffer;
                  ^
include/tty/tty.c:13:16: error: declaration for parameter 'terminal_color' but no such parameter
 static uint8_t terminal_color;
                ^
include/tty/tty.c:12:15: error: declaration for parameter 'terminal_column' but no such parameter
 static size_t terminal_column;
               ^
include/tty/tty.c:11:15: error: declaration for parameter 'terminal_row' but no such parameter
 static size_t terminal_row;
               ^
include/tty/tty.c:9:24: error: declaration for parameter 'VGA_MEMORY' but no such parameter
 static uint16_t* const VGA_MEMORY = (uint16_t*) 0xB8000;
                        ^
include/tty/tty.c:8:21: error: declaration for parameter 'VGA_HEIGHT' but no such parameter
 static const size_t VGA_HEIGHT = 25;
                     ^
include/tty/tty.c:7:21: error: declaration for parameter 'VGA_WIDTH' but no such parameter
 static const size_t VGA_WIDTH = 80;
                     ^
kernel.c:19:1: error: expected '{' at end of input
 }
 ^

[Ycep]

**Sigh**

Let me teach you a lesson (Pow!) about declaring, defining and usage of header files.

Header files are source code files which are used to make any function, variable, enum, #define, etc be public.
Declaring a function is thing that is required in header files, and required in some cases in normal source files.

Example:

Main.cpp

Code: Select all

#include"myheader.h"
#include<cstdio>
int main()
{
    printf("%d", add(2,3));
    return 0;
}

Basicarithmetic.cpp

Code: Select all

#include"myheader.h"
int add(int a, int b)
{
    return a+b;
}

myheader.h

Code: Select all

#pragma once
int add(int a, int b);

OR

Code: Select all

#pragma once
int add(int, int);

I hope we learned something today.

[heat]

Do we really want to teach basic C/C++ on an OSDev forum? Yeah, I don't think so. I'll just politely tell the OP to actually learn C instead of wasting our time.

[Schol-R-LEA]

You and half the forum. I think we've said that in every single thread NunoLava1999 has started, actually.

At least he finally listened about the cloud repo. That's an encouraging sign.

Oh, and just to make sure that what Lukand said was clear: the main issue is the presence (or absence) of what are called function prototypes. A function prototype declares the existence of the function to the compiler, whether it is in another source file, an object file that is already assembled or compiled, or further down the page in the same source file. It gives the name of the function, and (at minimum) the types of the parameters it takes. So, for example, if you have a function foo() that takes an unsigned int and a char array as its parameters and returns a char, and want to use it in your main() function, you could declare is with the the function prototype

Code: Select all

char foo(unsigned int, char[]);

Note the semicolon at the end; this indicates that it is a prototype, not the start of the function definition itself.

Now, while you don't (in older versions of C, anyway, I haven't checked C11's rules yet) need to put the parameter names in the prototype, it is generally a good practice to do so, to make the prototype more self-documenting (that is, giving the names of the parameters should help explain their purpose). Thus, you really should write it as

Code: Select all

char foo(unsigned int index, char foo_table[]);

which tells you that it is basically a wrapper around access to a table (which you might do in order to, say, provide some kind of validation on the table access).

You can put the prototypes anywhere in a source file so long as they appear before any place you use the functions, but since prototypes for library functions get used in several different places, you generally want to put those into a separate file which can be automatically inserted into the compiler's source code stream using the #include preprocessor directive. These are called header files, and are generally used to collect things like prototypes, type declarations, macro definitions, extern declarations of global variables, and pretty much anything else - so long as there are no functions declared inside it. The reason that you don't put function declarations in headers is because that would lead to the same function getting compiled in several places, making it impossible for the linker to resolve which copy of the function is the correct one (regardless of whether they are defined as the same or not).

So, if you use the header file as Lukand decribed above, for his Basicarithmetic.cpp file:

Code: Select all

#include"myheader.h"
int add(int a, int b)
{
    return a+b;
}

what the compiler actually sees is:

Code: Select all

int add(int a, int b);

int add(int a, int b)
{
    return a+b;
}

(The #pragma once line is a preprocessor directive telling it not to paste the code of a given header file into the current source stream more than once, even if it is included in another header file that is itself included
in the source stream.)

As you have probably guessed, you have already been using these include files all along; the standard headers such as <stdio.h> and so on are used to declare the standard library functions, such as printf() and pow(). These functions are not part of the language itself, but are in library files - object files which hold archives of several related functions - that are defined in parallel to the core language as part of the language standard.

Core C is actually a very, very small language, and except for those things that have special syntax for them (that is, things that aren't function calls, such as if(), for(), while() and so forth) most of the things that are thought of as being part of C are actually library code, not core language syntax. This is part of the advantage it has as a systems-programming language - you can define your own versions of the I/O functions and things of that nature, without conflicting with the standard ones so long as you tell the compiler not to use the standard ones (disabling automatic linking to standard library is part of what the GCC option -ffreestanding is for).

Anyway, as I said before, this wiki page explains the whys and wherefores of file inclusion, though at this point I have just covered most of what it has to say.

[MichaelFarthing]

Do we really want to teach basic C/C++ on an OSDev forum? Yeah, I don't think so. I'll just politely tell the OP to actually learn C instead of wasting our time.

He hasn't wasted any of my time. It's actually being wasted by everyone else in this thread.

Reason: He's registered as my foe* (actually the only foe I have - mainly because of the 'cates'). That means his posts all appear as two lines telling me that he's a foe and so his post is hidden. The only time I see his posts is when someone else quotes them. Hence, why it's everyone else's fault.

Those people that are kicking up a fuss should just learn some self-discipline: (a) don't read what you don't want to see (b) don't reply to what you think shouldn't be discussed here. (c) don't complain about those you disapprove of: it gives them more attention. Works wonders for a forum and also works wonders for ones own self-feeling-at-ease-ment.

[It'll also save a lot, lot, lot more space on the server than pruning the 10000 members].

*Go to the user control panel. Look for 'Friends and Foes' . Also, a propos another thread, you can turn off Private Messaging with a click of a button.

[Schol-R-LEA]

To be honest, the main reason I haven't done that (aside from the fact that I forgot about that feature) is my habitual didacticism - I really do want to help Nuno learn, and my frustration is mainly in the fact that he didn't seem to be listening to our advice. His antics about claiming to be nine, and other things like that, were annoying too, but the really frustrating part was the way he's kept ignoring our recommendations.

NunoLava, if I have said some rash or harsh things to you, I apologize. It was only because I thought you were making serious mistakes, and I hoped to let you know that there were better ways to do things.

[MichaelFarthing]

To be honest, the main reason I haven't done that...

My comment was not directed at you, Schol-R-Lea, but at us all (including, quite often, myself).

Thought I ought to say it explicitly because I seem to have been crossing swords with you in a number of threads, but in all cases it is with respect, in the spirit of proper discussion, and intended to be gentle. Hope that it hasn't seemed too otherwise.

[Schol-R-LEA]

Oh, no hard feelings at all. I understood that you meant that for the thread as a whole; I was simply stating the reason I hadn't done so already myself. I apologize if I was unclear.

[NunoLava1998]

To be honest, the main reason I haven't done that (aside from the fact that I forgot about that feature) is my habitual didacticism - I really do want to help Nuno learn, and my frustration is mainly in the fact that he didn't seem to be listening to our advice. His antics about claiming to be nine, and other things like that, were annoying too, but the really frustrating part was the way he's kept ignoring our recommendations.

NunoLava, if I have said some rash or harsh things to you, I apologize. It was only because I thought you were making serious mistakes, and I hoped to let you know that there were better ways to do things.

Okay. I was just taking a break since OSDev'ing is (this is not a quote that i made) nor hard, nor easy. It's very hard., which is why i was inactive for a bit of time.

[NunoLava1998]

I'm gonna try to replace my i686-elf-tools. I mean, if i change it to good' ol

Code: Select all

terminal_writestring("");

, same error. If a confirmed-to-be-working code fails for no reason, there's gotta be something wrong with my i686-elf-tools.

EDIT: Linker not the culprit. Same error.
EDIT: Compiler/Assembler not the culprit. What? Is my linker drunk? (it probably is beacuse 0x160 just points to a random point into a 34h byte, which is literally "4")

[iansjack]

If a confirmed-to-be-working code fails for no reason, there's gotta be something wrong with my i686-elf-tools.

Or, perhaps, the problem is that your confirmed-to-be-working code isn't confirmed-to-be-working. Just a thought.

"A poor workman blames his tools."

[NunoLava1998]

If a confirmed-to-be-working code fails for no reason, there's gotta be something wrong with my i686-elf-tools.

Or, perhaps, the problem is that your confirmed-to-be-working code isn't confirmed-to-be-working. Just a thought.

"A poor workman blames his tools."

Meh, time to read a C book.

[Schol-R-LEA]

Meh, time to read a C book.

Past time, I would say.

I'll take a look at your code in the repo, and I will try to come up with some advice about it.

I did notice that in your multiboot stub, you set ESP to stack_top (the label marking, and just past, the lower end of the block you set aside for the stack in memory), which I think you might need to reconsider - it might not be related to the current issue, but stack overruns can cause unpredictable results. Setting the initial value of the stack pointer to the lower end of a downward-growing stack - or worse, after the lower end of said stack - will, at the very least, overwrite the boot stub once the stack starts getting used - something which in this case happens in the very next instruction, which is in fact within the 4 bytes that the next stack value will be pushed onto.

It's the sort of thing anyone could do, because it sounds like the right place to initialize it to at first and is something most coders would be unlikely to revisit when debugging a program unless they have experience in precisely this sort of bug. Don't feel bad, I think I (and most other coders) have made far sillier mistakes before, and probably will sometime in the future, too.