Link resulting in malfunctioning OS

[CRoemheld]

I don't know how to name the topic, as I don't have a clue where the exact problems lies.

Right now, I am compiling my *.c and *.s files using my cross compiler (from the Bare Bones tutorials) and copy them into a bin/ directory. After that, I use the linker and try to get an ELF file containing my loader for the 64bit kernel. The following image shows the output with some code from the Bare Bones tutorial (This is the working code):

http://imagizer.imageshack.us/a/img922/9294/1HC3Pc.png

But after I add two more files to the loader (The ones marked in blue in my directory), the linker is creating a malfunctioning elf file, because the OS does not show anything anymore.

http://imagizer.imageshack.us/a/img924/2696/UT75Lt.png

I tried the following:

• - Change the order of the files which are linked in the end -> no changes in the OS
  - Remove one of the additional files -> I can remove the bootstrap_paging.c file and it works fine, so I assume the problem is there somewhere
  - Check for undefined symbols: No symbol is undefined

What could be the cause for such a development? (Should I even put the code of my whole bootstrap_paging.c source file in here?)

EDIT: To complete the post, I added the link to the broken OS > here <.

[iansjack]

Should I even put the code of my whole bootstrap_paging.c source file in here?

No, definitely not, but you should provide a link to an online repository (e.g. GitHub) containing all of your source code, including any linker script file and the commands that you use to make your program (presumably in a make file.

Without that information it's unlikely that anyone can guess what your problem is.

[CRoemheld]

Should I even put the code of my whole bootstrap_paging.c source file in here?

No, definitely not, but you should provide a link to an online repository (e.g. GitHub) containing all of your source code, including any linker script file and the commands that you use to make your program (presumably in a make file.

Alright, I reduced the code to a minimal "crashing" example: See here

You will need an i686 cross compiler for this. If you run make in the root directory of the project, and leave the src/bootstrap/bootstrap_paging.c file in the linker, the build crashes on start. If you remove the bootstrap_paging.c file from the linker process, the build is working fine.

[iansjack]

I've had a quick look at your code, and you have a problem when first setting up the stack pointer.

When looking at the generated code we have:

Code: Select all

10001c:       8b 25 14 60 10 00       mov    0x106014,%esp

which moves the contents of 0x106014 into esp rather than the immediate value. The line should be:

Code: Select all

10001c:       8b 25 14 60 10 00       mov    $0x106014,%esp

Now this is in AT&T syntax and I see that you are using Intel syntax, which I am not totally au fait with. But I believe that instead of the labels

Code: Select all

stack_bottom:
stack_top:

you should have

Code: Select all

stack_bottom
stack_top

(i.e. no colons). It's possible that you have similar errors elsewhere in your code.

The result, in this case, is that the program crashes when returning from "vga_initialize". I haven't looked into it far enough to know exactly why, but it may be because the stack pointer starts with an odd value, which is a definite no-no.

I hope this gives you enough to investigate further.

(To determine this I used "objdump" to investigate the generated code and I single-stepped your program using AMD's SimNow emulator.)

[CRoemheld]

Thanks for your answer!

Now this is in AT&T syntax and I see that you are using Intel syntax, which I am not totally au fait with. But I believe that instead of the labels

Code: Select all

stack_bottom:
stack_top:

you should have

Code: Select all

stack_bottom
stack_top

(i.e. no colons). It's possible that you have similar errors elsewhere in your code.

No, because if I remove the colons the

Code: Select all

stack_top

and

Code: Select all

stack_bottom

are compiled as instructions, which results in an error on compile time.

About the setup of the stack, this is the correct way, because in intel syntax you don't have any prefixes like $, which means the conversion from AT&T to Intel completely gets rid of all prefixes like $ for constants and % for registers. For moving the contents of a memory location, you explicitily have to use brackets, e. g.:

Code: Select all

mov eax, [ecx]

or in this case if I would have moved the contents of stack_top,

Code: Select all

mov esp, [stack_top]

But since in Intel the prefixed are obsolete, moving stack_top as a value is the same as moving $stack_top in AT&T.

So unfortunately, this is not the reason for the problem.

[iansjack]

As I said, I'm not really familiar with Intel syntax - in particular using it with the GNU assembler. But, for whatever reason, your code is loading the wrong value into the stack pointer. Both wrong in the sense that it is not the address you intend and in the sens that it is an invalid value.

I'll have a look further but, in the meantime, you might like to investigate why the wrong code is being produced.

Edit: Just as a matter of interest, what is the version number of your assembler?

[iansjack]

I've played around a bit more and everything I try emits the wrong code.

But I have got a workaround for you. Replace the offending line of code in boot.s with

Code: Select all

.att_syntax
#	mov esp, stack_top
        mov $stack_top, %esp
.intel_syntax noprefix

Horrible, I know, but it does produce the correct code, and the program then runs.

The real answer (IMO) would be to use AT&T syntax which is the native sytax for the GNU assembler. It does appear to have a number of problems with Intel syntax.

I am aware that many will disagree with this solution. Alternatively, you could use a different assembler.

[CRoemheld]

I've played around a bit more and everything I try emits the wrong code.

But I have got a workaround for you. Replace the offending line of code in boot.s with

Code: Select all

.att_syntax
#	mov esp, stack_top
        mov $stack_top, %esp
.intel_syntax noprefix

Horrible, I know, but it does produce the correct code, and the program then runs.

You are right, I was actually only using Intel syntax because that was the one I was familiar with. But it seems the AT&T syntax seems to be more reliable in OS development, whatever the reason might be. Maybe there's a way for the intel syntax to get this to work, but I couldn't find anything so far.

The real answer (IMO) would be to use AT&T syntax which is the native sytax for the GNU assembler. It does appear to have a number of problems with Intel syntax.

I am aware that many will disagree with this solution. Alternatively, you could use a different assembler.

I was actually thinking about switching to AT&T syntax not too long ago, but it seems now that I have found a reason for switching from Intel to AT&T.
Thanks a lot for your time!

[simeonz]

Disassembling the output from the original source gives:

Code: Select all

Disassembly of section .text:
...
    4004:       8b 25 00 40 00 00       mov    0x4000,%esp

Disassembling the output with iansjack's modification gives:

Code: Select all

Disassembly of section .text:
...
    4004:       bc 00 40 00 00          mov    $0x4000,%esp

In both cases there is a relocation at the mov. Looking at this reference, the first instruction opcode is for a mov with a memory operand (, which is what you normally expect [name] to do) and the second is for mov is with an immediate operand, which is what you need to happen.

Apparently gas offers an unconventional intel syntax. See this SO answer. Using the offset operand prefix as described there fixes the issue. However, there are other subtle differences (literal radix prefixes "0x" instead of suffixes like "h") and there appears to be no official documentation regarding the syntax.

[CRoemheld]

Thanks for your input, simeonz!

Ah, alright the offset prefix was apparently what I missed for intel syntax. Thats good to know for future projects!
I decided to completely switch to AT&T, since most of the tutorials and codes to look into are using it. Also I have the feeling using AT&T gives a better overview about what is happening there, because the prefixes also help me distinct between registers, constants etc. The only thing which will probably irritate me for a while is the order of source and destination, as they are switched in AT&T and Intel.

[iansjack]

Ah, "offset"; that's what I couldn't find.

One of the things I like about AT&T is the order of the operands. It seems natural to me that you are moving A to B rather than moving B to A. Anyway, it's been an education. It's always good to learn something new each day.