stddef isn't being included, uintX_t types not found(Solved)

[Mikumiku747]

I got the Meaty_Skeleton project working (as well as bare bones), and fixed up the putchar function to handle newlines, and now I'm trying to implement inb and outb functions so I can start work on a keyboard driver. But for some reason, my files aren't getting stddef included with them, even though it's supposed to be integrated into the compiler.

To get to this point, I appended the entry in the libc makefile which describes which freestanding files to build, to include inb.o and outb.o, and made a header file called io.h in the include folder of libc, as well as inb.c and outb.c in libc/io. I included stddef in all of the files, so I'm not sure why the compiler doesn't recognise the types uint8_t and uint16_t?

Below are the changes I made to meaty skeleton:

New files:

Code: Select all

libc/
    include/
        io.h
    io/
        inb.c

Changed files:

Code: Select all

libc/
     Makefile

io.h

Code: Select all

/* libc/include/io.h */
#ifndef _IO_H
#define _IO_H 1

#include <sys/cdefs.h>

#include <stddef.h>

#ifdef __cplusplus
extern "C" {
#endif

	uint8_t inb(uint16_t port);

#ifdef __cplusplus
}
#endif

#endif

inb.c

Code: Select all

/* libc/io/inb.c */
#include <io.h>

uint8_t inb(uint16_t port) {
	uint8_t result;
	asm("in %%dx, %%ax;"
		:"=a" (result)
		: "d" (port)
		);
	return (uint8_t)result;
}

libc/Makefile (Added inb.o on the end of the freestanding object files list)

Code: Select all

Lots of other stuff
...
FREEOBJS:=\
$(ARCH_FREEOBJS) \
stdio/printf.o \
stdio/putchar.o \
stdio/puts.o \
stdlib/abort.o \
string/memcmp.o \
string/memcpy.o \
string/memmove.o \
string/memset.o \
string/strlen.o \
io/inb.o \
...
More stuff

Here's the error message I get when using build.sh to build the OS:

Code: Select all

Skipping to where it actually compiles my object file
...
i686-elf-gcc --sysroot=/home/Daniel/OS_Stuff/meaty-skeleton/sysroot -isystem=/usr/include -c io/inb.c -o io/inb.o -std=gnu11 -O2 -g -Wall -Wextra   -D__is_myos_libc -Iinclude
In file included from io/inb.c:1:0:
include/io.h:12:2: error: unknown type name 'uint8_t'
  uint8_t inb(uint16_t port);
  ^
include/io.h:12:14: error: unknown type name 'uint16_t'
  uint8_t inb(uint16_t port);
              ^
include/io.h:13:11: error: unknown type name 'uint16_t'
  void inb(uint16_t port, uint16_t value);
           ^
include/io.h:13:26: error: unknown type name 'uint16_t'
  void inb(uint16_t port, uint16_t value);
                          ^
io/inb.c:3:1: error: unknown type name 'uint8_t'
 uint8_t inb(uint16_t port) {
 ^
io/inb.c:3:13: error: unknown type name 'uint16_t'
 uint8_t inb(uint16_t port) {
             ^
Makefile:67: recipe for target 'io/inb.o' failed
make: *** [io/inb.o] Error 1
make: Leaving directory '/home/Daniel/OS_Stuff/meaty-skeleton/libc'

I'm just stumped, and can't figure out as to why it doesn't like the typedefs. I can manually include a file of typedefs if I need to (I think), but I'm curious as to why the compiler doesn't like it. I used those types in some stuff I did with the bare bones tutorial and it seemed to work fine. I have a hunch that for some reason the inb.c file is just getting compiled on it's own, but I'm not sure what I should do to the makefile to get it to work. I didn't see any other relevant parts of the makefile.

I'm using a 64 bit windows 8.1 computer with cygwin, compiling with an i386-elf cross compiler (although I have to use grub-mkrescue on a virtual machine) and I can upload a zip or tarball of the project if you really need it, but I'm hoping somebody can spot the problem or suggest some troubleshooting techniques I could use based on what they see in this post.

[KemyLand]

You're missing some things.

First, what does this do?

Code: Select all

--sysroot=/home/Daniel/OS_Stuff/meaty-skeleton/sysroot -isystem=/usr/include

I don't work with Cygwin, (Linux instead) so I'm not sure if this is a "pretty hack you need for Cygwin." But my kernel does not does this even a single time. This is rather used when building the userspace cross-compiler. For the sake of sanity, remove that "-isystem=/usr/include"! This will pull on all your hosted system headers!

Secondly, you're missing some compiler flags:

Code: Select all

-ffreestanding -Werror

The last of which may make your build fail. That's good, because you're uncovering darkened warnings! Just repair them and everything'll be ok.

Thirdly, are you gonna mix C and C++ in your kernel? Otherwise, why...?

Code: Select all

#ifdef __cplusplus
  extern "C" {

And last, but not less important, take a look at your in/outb/w/l() prototypes. Some are wrong.

Post any other problems you may have in the road .

If everything of this fails still, I would want to see your <sys/cdefs.h>.

EDIT:
Just saw that famous Meaty Skeleton tutorial (never saw it), and I'm looking it has some things wrong, specially tending too much to userspace-style kernel programming. I'll modify it when I have time. BTW...

Normally when you compile programs for your local operating system, the compiler locates development files such as headers and libraries in system directories such as:
/usr/include
/usr/lib
These files are of course not usable for your operating system. Instead you want to have your own version of these directories that contains files for your operating system:
/home/bwayne/myos/sysroot/usr/include
/home/bwayne/myos/sysroot/usr/lib

Highlightning done by myself. Although the tutorial is okay in saying that you shall not use /usr/*, it's still (somewhat) wrong in saying that you should have a sysroot for the kernel. That's just stupid. In the first place, a normal kernel does not share no includes with userspace roots! Secondly, No sane kernel uses something inside /myfolder/lib!. Thirdly, although this is technically correct, it has been proben to be a very bad design. The kernel is a separate environment and shall not be treated as userspace, as this tutorial does.

[alexfru]

It would probably be a good idea to check with a C or C++ language/library reference on this.
Hint: uint8_t and such aren't in stddef.h.

[KemyLand]

It would probably be a good idea to check with a C or C++ language/library reference on this.
Hint: uint8_t and such aren't in stddef.h.

Just missed that little bit when writting my post . Use stdint.h instead, although I'm not sure if it's provided by freestanding compilers...

[Mikumiku747]

Thanks both for the help, I'm quite new to this, so I kind of just used the meaty skeleton tutorial as a base and started working outwards from there, I had no idea it was so fragile. I'm not that new to C, but I've still got a lot to learn, but I think I understand the core mechanics of the language well enough, so I'm kind of lacking in some of the knowledge that only comes from experience. In any case, both the answers were quite helpful, I'll get back to you when I've got it fixed.

Again, thanks.

[KemyLand]

Thanks both for the help, I'm quite new to this, so I kind of just used the meaty skeleton tutorial as a base and started working outwards from there, I had no idea it was so fragile. I'm not that new to C, but I've still got a lot to learn, but I think I understand the core mechanics of the language well enough, so I'm kind of lacking in some of the knowledge that only comes from experience. In any case, both the answers were quite helpful, I'll get back to you when I've got it fixed.

Again, thanks.

If GCC happens to not providing stdint.h in freestanding environments, use this by the moment. With your target, it'll be okay:

Code: Select all

typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef short int16_t;
typedef unsigned short uint16_t;
typedef int int32_t;
typedef unsigned uint32_t;
typedef long long int64_t;
typedef unsigned long long uint64_t;

[sortie]

Yes. You want to use stdint.h for this. It's also freestanding and its use is demonstrated in bare bones. No, meaty skeleton is not fragile. It's working as designed.

KemyLand:

I suggest you learn what you are talking about before you talk about it. I wrote meaty skeleton and I assure you that --sysroot=... and -isysroot=/usr/include are very much intentional. In fact, the = symbol in -isysroot is not an assignment, but actually special compiler syntax where = means the sysroot, so $sysroot/usr/include is used for system headers. -Werror by default is bad, because not all warnings are errors, it is only to be used as -Werror=foo when you want to make foo a warning (blacklisting), or as -Werror during personal development when you want to prune warnings. -ffreestanding is not needed for that particular io/inb.o file because it is going into the userspace libc. The libk edition will be built shortly and does need -ffreestanding. The #ifdef __cplusplus extern "C" { sequences is such that user-space C++ programs can use the system headers. A sysroot is useful for the kernel, believe it or not. For instance, in meaty skeleton the libk is installed into the sysroot, and the kernel can link against it with -lk and the system headers can be easily included. I assure you this is not a bad design, I've used it for years very successfully. Note how the libc (which is unsafe for kernel use) has a freestanding libk counterpart that is explicitly designed to be safe for kernel use.

-isystem=/usr/include is needed because i686-elf-gcc does not have a system include directory. When you switch to an [ur=http://wiki.osdev.org/OS_Specific_Toolchainl]OS specific toolchain[/url] you will get such a directory and should remove this and just --sysroot=... will do the trick.

Please don't edit meaty skeleton for things you think are wrong without consulting me first. You'll find that I'm very much deliberate in a lot of these semantics due to reasons you might not know. The sharing of code between libc and libk is fine and leads to less code duplication. Please share any other problems you see in it, though, I would very much like for it to become bugless.

GCC does provide a freestanding stdint.h and you should not supply your own poor replacement. stdint.h is freestanding. That's a concept from the C standard that a header can be used in the freestanding environment. Note however, this header only works when -ffreestanding (it checks __STDC_HOSTED__). Your libc should later on supply its own replacement header. GCC provides special predefined macros that you should use, see Sortix <stdint.h> and<__/stdint.h>. Your 64-bit types are wrong for x86_64, btw, the ABI mandates you pick the smallest datatype that has the right size, so on i386 int64_t is long long, but on x86-64 it is just long. In other words, the stdint types might depend on the processor target. That's why the compiler provided macros are useful. Note how the compiler actually has an opinion on what types like int64_t should be and it actually uses this opinion when generating printf warnings with -Wformat.

Edit: Looks like I never got around to use the compiler predefined macros for stdint. No worries, this approach works too.

[Mikumiku747]

OK, I've taken a step back, looked at things, and realised that the meaty skeleton is a bit too crazy for me right now. I'm trying it as my second tutorial, but I think it's something I shouldn't really consider until I get to the point where I want to implement a userspace. In any case, I should leave it alone seeing as I don't even have input yet. But I'll come back to it eventually when I'm more prepared for something like that.

However, not all is lost though, I did learn a few things (I hope) about all that /usr/include stuff. I think for now I'll stick to expanding the bare bones into something more reasonable. Thanks for teaching me that stdint.h is NOT one of the freestanding compiler headers, and the help with the gcc compiler options, particularly Werror (Which seems like a good sanity check, why wouldn't I enable it all the time?), and lastly, that there's an actual standard for the C library, which I was pretty stupid not to realise, but oh well, I know now.

I'm sorry I wasted your time, I should have looked the tutorial code through a bit more thoroughly. Thanks for the help.

[sortie]

Note that stdint.h is freestanding, but there's no agreement on who supplies it (compiler of standard library) due to historic reasons. Meaty skeleton is meant to make it easier for you to add a userspace later on because it's basically ready for one, it uses a design that scales. Either way, it's just an example, feel free to do things wholly different.

[Mikumiku747]

Note that stdint.h is freestanding, but there's no agreement on who supplies it (compiler of standard library) due to historic reasons. Meaty skeleton is meant to make it easier for you to add a userspace later on because it's basically ready for one, it uses a design that scales. Either way, it's just an example, feel free to do things wholly different.

Yeah, I think that this tutorial isn't really better suited for me right now, (I was just looking for a hint on where to go once I get bored of a a kernel all alone by itself, what's the deal with those rings?), but I'm still confused as to how I tell the compiler whether I want a freestanding stdint, as opposed to my own/another stdint. Is it really just using the -ffreestanding option?

Also, this might be a dumb question, but which standard should I try to make my functions adhere to? I've heard of ANSI C (which I think is really old) and c99, but are there any others, and can I find a place that shows the differences between them? I bring this up because I don't want to have to re-write my functions in the future when I find out there's a good standard everybody follows, but I've been following some standard from the 60s. Any personal reccomendations?

[KemyLand]

Note that stdint.h is freestanding, but there's no agreement on who supplies it (compiler of standard library) due to historic reasons. Meaty skeleton is meant to make it easier for you to add a userspace later on because it's basically ready for one, it uses a design that scales. Either way, it's just an example, feel free to do things wholly different.

Yeah, I think that this tutorial isn't really better suited for me right now, (I was just looking for a hint on where to go once I get bored of a a kernel all alone by itself, what's the deal with those rings?), but I'm still confused as to how I tell the compiler whether I want a freestanding stdint, as opposed to my own/another stdint. Is it really just using the -ffreestanding option?

Also, this might be a dumb question, but which standard should I try to make my functions adhere to? I've heard of ANSI C (which I think is really old) and c99, but are there any others, and can I find a place that shows the differences between them? I bring this up because I don't want to have to re-write my functions in the future when I find out there's a good standard everybody follows, but I've been following some standard from the 60s. Any personal reccomendations?

Yes, -ffreestanding does most of the job for enabling freestanding mode. With respect to the standards, do *not* use ANSI C, it's too old. Adhere to either C99 (volatile, inline, etc...) or C11. If you are using C++, please use C++11, not C++98. BTW, use -std=gnu11 instead of -std=c11. Do not use -pedantic. You will need GNU extensions sooner or later (have you seen some GNU extensions that are very rare? They come from the Linux kernel's needs of course ).

[sortie]

but I'm still confused as to how I tell the compiler whether I want a freestanding stdint, as opposed to my own/another stdint. Is it really just using the -ffreestanding option?

All you need to do is just use the compiler provided stdint.h if you're compiling with -ffreestanding and still using a i686-elf-gcc (or any such bare target gcc). If you have code not compiled with -ffreestanding or switch to an OS specific toolchain (do this when you add userspace), you need to supply your own stdint.h. It doesn't hurt to supply your own (assuming all the things it should) early on though (but it might not be used if -ffreestanding and *-elf-gcc). Those are the rules.

Meaty Skeleton builds a useless libc.a. That doesn't matter, but that means some code gets built as userspace, and if that uses stdint.h, there's trouble as you see here. I think I'll disable that from meaty skeleton to avoid this confusing issue.

Also, this might be a dumb question, but which standard should I try to make my functions adhere to? I've heard of ANSI C (which I think is really old) and c99, but are there any others, and can I find a place that shows the differences between them? I bring this up because I don't want to have to re-write my functions in the future when I find out there's a good standard everybody follows, but I've been following some standard from the 60s. Any personal reccomendations?

You want POSIX 2008 (2013 revision) (a base standard for Unix-like system interfaces that extends C99 (C11 came after its publication, but it is largely identical to C99)) and C11 (the latest revision of the C standard). Following POSIX will make your code more compatible and portable. It's a sleek standard with a reasonable core that doesn't impose too much, and then various extensions that range from good to bad (standardizing functions that are terrible for compatibility reasons). You can pick a subset of POSIX you like (or all of it) and implement that correctly and get a lot of compatibility with existing software. To port software later on, see Cross-Porting Sofware which takes advantage of the meaty bones way of structuring things.

[KemyLand]

You want POSIX 2008 (2013 revision) (a base standard for Unix-like system interfaces that extends C99 (C11 came after its publication, but it is largely identical to C99)) and C11 (the latest revision of the C standard). Following POSIX will make your code more compatible and portable. It's a sleek standard with a reasonable core that doesn't impose too much, and then various extensions that range from good to bad (standardizing functions that are terrible for compatibility reasons). You can pick a subset of POSIX you like (or all of it) and implement that correctly and get a lot of compatibility with existing software. To port software later on, see Cross-Porting Sofware which takes advantage of the meaty bones way of structuring things.

BTW, POSIX is an excellent idea (at least for compatibility...), but on Kernel Space, be free as in freedom . That is, if you don't want to, do not stick to a hosted-C style kernel. When writting kernel code, the only thing that POSIX mandates you are the system calls.

[KemyLand]

I suggest you learn what you are talking about before you talk about it. I wrote meaty skeleton and I assure you that --sysroot=... and -isysroot=/usr/include are very much intentional. In fact, the = symbol in -isysroot is not an assignment, but actually special compiler syntax where = means the sysroot, so $sysroot/usr/include is used for system headers. -Werror by default is bad, because not all warnings are errors, it is only to be used as -Werror=foo when you want to make foo a warning (blacklisting), or as -Werror during personal development when you want to prune warnings. -ffreestanding is not needed for that particular io/inb.o file because it is going into the userspace libc. The libk edition will be built shortly and does need -ffreestanding. The #ifdef __cplusplus extern "C" { sequences is such that user-space C++ programs can use the system headers. A sysroot is useful for the kernel, believe it or not. For instance, in meaty skeleton the libk is installed into the sysroot, and the kernel can link against it with -lk and the system headers can be easily included. I assure you this is not a bad design, I've used it for years very successfully. Note how the libc (which is unsafe for kernel use) has a freestanding libk counterpart that is explicitly designed to be safe for kernel use.

I do know what I'm talking about, and I know that this design confuses users, and shall be introduced later on, not directly after Bare Bones. That makes it pretty fragile. Please, let's not start a flamewar just by my opinion about Meaty Skeleton . Beginners are not ready for this. Including direct C++ support? AFAIK, they do not mix both languages from the start!

You're completely wrong on saying that -Werror is bad. The fact that you avoid it makes me suspect that you use some hacks you shouldn't. My kernel compiles perfectly with it, so why yours don't (maybe)?

I respect your libk design, but it's not my way of doing things. Why do you introduce userspace stuff when they haven't even touched the IDT/GDT/PIT/etc... yet? You said it ina later post, it's just useless (and confusing) at the moment. Why do you use it as a full-fledged library, and not as a separate folder of the kernel's sources? That's just a waste of compiler/linker time, and this implies the use of sysroots, that are, again, innecessary and confusing at the moment.

Please don't edit meaty skeleton for things you think are wrong without consulting me first. You'll find that I'm very much deliberate in a lot of these semantics due to reasons you might not know. The sharing of code between libc and libk is fine and leads to less code duplication. Please share any other problems you see in it, though, I would very much like for it to become bugless.

Again, no flamewars, please? What are those reasons I might not know? I know what's wrong (may I use "confusing" instead?) with Meaty Skeleton. The fact that it directly imposes your design to newcomers is not good, when there are more straightforward (and let me say this: less bug and error prone, as show by this own thread) ways to do such simple things as the OP is trying to do. Less code duplication? Give me an example please. And yes, I'll share any other problem I may find. But let's accept it, it's after all, an excellent design for your needs, but not for newcomers like the OP. I'll, however, consult you before doing anything. But you already said you'll do some edits, so I'll leave it to you.

[sortie]

KemyLand, the goal of Meaty Skeleton is not that newcomers must use it or do it in exactly this way. The goal is to show a way to structure an operating system in a way that scales all the way to self-hosting. The goal is not to use confusing concepts, but to introduce crucial concepts like sysroots that are massively useful when cross-compiling user space code. It's not whether newcomers are ready for this, it's a matter of showing these concepts exist so they can learn, so they know where to look when they do need them. The goal is to show what issues a build system might face, so when users pick or make their own build system, they think about this stuff.

Sorry, my point about -Werror was unclear. -Werror by default is bad because not all warnings are errors. For instance, binutils builds with -Werror by default, then gcc adds new warnings, and after upgrading your compiler, binutils no longer compiles. What went wrong? Binutils is no more buggy than it was before, but because gcc had a false positive on a minor new warning, everything broke. The purpose of -Werror is to help prune warnings from the codebase, but it doesn't help users. My point is that projects should not use -Werror by default because warnings are not errors. -Werror whenever a develop wants to get rid of all warnings, this is fine. -Werror=foo whenever you consider -Wfoo an errror is fine too. Telling people to always supply -Werror is harmful because it makes stuff break when other people build it in another configuration than the developer.

(Note that I systematically get rid of warnings and prune hacks from my code base. My verify-before-git-push script builds for multiple architectures with -Werror for instance.)

When I say code duplication above, I am talking about having a strlen function in both libc and in the kernel. That's two implementations that need to be maintained. The same goes for printf, memcpy, and all the other things you want both places. This can be acceptable and many kernels do it. I personally would not like to maintain two versions of the same function.

I'll think about making it more clear that Meaty Skeleton is an example template and entirely optional. However, build systems and organization is best done early on, as one of the first things done in a new project is to add a build system and put files somewhere. For instance, many new projects put the kernel in the main directory, here they see the kernel is just one component and it makes sense to put it in a kernel subdirectory.