This is a hard question to ask because I'm positive I'm about to be bombarded with haters commenting on "if I can't write an operating system already, I won't ever to be able to write an operating system". Well I've read Modern OS by Tanembaum, Linux Kernel Development, Understanding the Linux kernel and others I still don't know if or not I can write an operating system and only by pushing forward to write one will I realise what I don't know. On top of that none of the books I read even bother to describe the boot sequence / compilation sequence.
Anyway I hate to be negative but I would just like to build the example code from the bkerndev tutorial below and have an absolutely minimum operating system:
http://www.osdever.net/bkerndev/index.php?the_id=90
You can download the associated source code in a zip format from here:
http://www.osdever.net/bkerndev/bkerndev.zip
When you try and compile this kernel you run into all sorts of errors caused by the fact that some of the code is broken. Another user was seeking help for this here on stack overflow here:
compiling my own kernel (not from linux-kernel source)
Although didn't get much help. I have addressed those errors by adding the gcc flag fleading-underscores and by changing some of the data types. You can see my code here:
http://github.com/PhillipTaylor/farmix
The code will compile sucessfully and leave me with a kernel.bin executable but when I boot into it from grub I get:
Error 13: Unrecognised or unsupported format (or something to that nature)
When I take the kernel.bin directly from the authors zip file and run it on my eeepc it boots absolutely fine so I think I have a problem with compiling the code correctly. The author is building it from a Windows machine, I believe, but I am trying to compile it using Fedora 10 i386 with GNU GCC 4.3 and I think this is what is causing the issue so I ask you, how do I build a valid executable kernel? Am I missing the correct target or the wrong binary format?
I would really appreciate someone helping me over this embarrassing "first step"
My comment above wasn't very clear. What I meant is "What does the 'file' command report on your kernel.bin vs. theirs?". The output of the linker is a raw binary file. It should start with a few magic words that grub recognizes. They are defined in start.asm near "mboot". I suspect yours is different than theirs.
I don't have nasm handy so I can't build, but you might want to start by comparing the first few words of the .bin file.
It turns out that the line used to compile the app was explicitly set to compile to "aout" format which was what the guide said and what I assumed to be true. Only reading stuff in the "barebones" guide convinced me that I may have been confused. As soon as I changed that one line to "nasm -f elf" it all worked.
This is a tag in my repository that points to a basic WORKING version of bkerndev tutorial code (How to write your own Operating system) for future reference and people who were in my position..
It comes with a makefile for building it from a 32 bit Linux system.
http://github.com/PhillipTaylor/farmix/tree/bkerndev_tutorial_working
Related
A weeks ago, I started learning about the Triangle program, which is used to generate meshes.
I attach the link from where you can download its zip file and read about it:
http://www.cs.cmu.edu/~quake/triangle.html
I am having trouble running the example using in Linux Ubuntu, which is supposed to be run trivially.
In particular, I don't understand what are exactly the switches that are mentioned in the makefile.
How exactly am I supposed to choose the optimization using switches? Do I need to modify the C source code or is something I need to specify before compiling it on Linux terminal somehow?
Besides, I am required to use the -DLINUX switches in order for arithmetics to run well. I would also need to know where I need to specify this.
If it helps, I am getting errors in the terminal notifying me that there are: "Undefined reference to sqrt" and " "Undefined reference to cos".
I really need help on this because my understanding on Linux and C is quite weak.
Thanks very much.
tl;dr
I can't compile glibc on powerpc/mips/armeb/sparc. How can I test bigendian without emulating a whole system?
Problem Description
I am currently trying to test some code to ensure that it works on a big-endian system (it doesn't) and fix any big-endian errors. Currently I am using qemu-system-ppc with a PowerPC debian image and compiling within that image, as well as running gdb there, etc. However, this is extremely inefficient and I know there is a better way.
As such I followed this tutorial to create a cross compiler so I could compile my source to a big-endian system, then run the user-space qemu-??? to test it without the overhead of running the entire OS in emulated space (in particular with the -S switch I could run gdb on host which is much faster).
Attempt #1:
First try was powerpc. At first I just ran the configure with --target=powerpc but realized that I should use a full triplet and went with powerpc-unknown-linux-gnu. Unfortunately, when I get to the glibc portion I run into the problem that my gcc does not support IBM 128-bit long doubles (it only supports IEEE). I googled around and there doesn't seem to be a fix (aside from updating gcc past v4.1 - I'm at 6.2 right now).
Attempt #2:
Let's try mips then, I have more experience with it anyways (from university). This makes it to the glibc portion again, but this time it complains that it can't determine the ABI. I tried it with all of -linux-gnu -gneabi -eabi and -none but it couldn't determine the ABI for any of them.
Attempt #3:
Alright, time to try armeb. This time it gets past determining the ABI, then dumps a message saying that the target is not yet supported by glibc. Same story with sparc.
Question
Given that all of the above failed - how can I compile a cross-compiler from my little-endian system to a big-endian system which will generate executables I can run in user-space with qemu?
I have seen a document here http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. This example is all about crash seen in Windows file? I am looking for the same mathematics that has been done here for the crash generated on Linux systems. If I get the crash on Linux, then how will I debug the issue in the similar lines like Microsoft document http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. Please help?
Is load address and the code segment address are same in Linux? what is the following in Linux as mentioned in the link "The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long."?
PE is windows format. Linux uses ELF. Of course you can parse ELF manually, but you shouldn't - gdb could do that for you. Even more, you can use addr2line utility to map address to file/line in source code (of course both of these will require debug build).
Map files are rarely used in linux - it usually just a part of debug executable. It could be dumped from debug build, however, but it don't have too much practical value.
Also, take a look at How to use addr2line command in linux
I am an intermediate C programmer who is learning his way around. I recently learned using GDB (forced to actually) and also am doing some code using Ptrace.
I was browsing through some code on ptrace and came across "DEBUG INFO".
I want to know what this means and when should I include this in my code?
What are debug info files?
I couldnt find much from google and wiki related to this. There is no wiki for that tag too.
May be if you can point me to the right direction I can repay by writing one.
DEBUG_INFO you are referring to is probably just an option (and define) of linux kernel. Enabling it when configuring kernel tells compiler to include debug information in resulting binary. This debug information itself is just additional data, that allows debuggers (and other tools like strace, addr2line, gprof, ...) relate binary code it's executing to source it was compiled from (source lines, variable names, etc, etc). You can find more details on debug information in general starting at DWARF (popular debug data format).
check for what is a core dump .you might get some directions.
The whole credit goes to Peter for the answer.
Initially I went through "What is core dump"
Then I came across the following link which actually tells the difference between
Debug Build
Release build
which is: debug build includes debug information while a release built doesn't have these and is Optimized code.
Also this answer can help you get more information.
I'm on an XP Virtual Machine running the GNU Visual Debugger 1.2.6, trying to open an Ada file (.adb), but keep getting the following error:
not in executable format: File format
not recognized
I should also mention that I've installed both the Ada compiler kit and win32 tools for GNAT 3.14p.
I've since tried opening other .adb files from the GVD and even .c files, but all with the same happy response above.
Any idea why this is happening?
GVD does not take a source file as an argument, it takes an executable program. Skipping a lot of if this and if that, to debug foo.adb you probably want to pass foo.exe to the debugger.
But this is Ada, and you shouldn't be here. ;-) If you got your source program to compile and produce an executable, you very seldom need to run the debugger. I can remember the last time I used the debugger with GNAT, and why. (A bug in Solaris, the workaround was change a constant to a variable--Solaris was overwriting the value passed in instead of using a temp.) But that was what? Five years ago?
It is much easier to put in some debugging code (see pragma Debug in the GNAT documentation), then run the program with the debug flag if necessary.
Oh, most important. You may need to look in C:\GNAT\2010\share\doc\ to find all the documentation that came with GNAT. Read it. Or at least figure out how to search it for what you need. ;-)