OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 7:17 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: Link resulting in malfunctioning OS
PostPosted: Mon May 21, 2018 4:53 pm 
Offline
Member
Member

Joined: Wed May 02, 2018 1:26 pm
Posts: 55
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 <.


Last edited by CRoemheld on Tue May 22, 2018 10:44 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Tue May 22, 2018 1:14 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
CRoemheld wrote:
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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Tue May 22, 2018 7:35 am 
Offline
Member
Member

Joined: Wed May 02, 2018 1:26 pm
Posts: 55
iansjack wrote:
CRoemheld wrote:
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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 5:57 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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:
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:
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:
stack_bottom:
stack_top:
you should have
Code:
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.)


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 8:11 am 
Offline
Member
Member

Joined: Wed May 02, 2018 1:26 pm
Posts: 55
Thanks for your answer!

iansjack wrote:
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:
stack_bottom:
stack_top:
you should have
Code:
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:
stack_top
and
Code:
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:
mov eax, [ecx]
or in this case if I would have moved the contents of stack_top,
Code:
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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 9:06 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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?


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 9:51 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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:
.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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 10:47 am 
Offline
Member
Member

Joined: Wed May 02, 2018 1:26 pm
Posts: 55
iansjack wrote:
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:
.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.

iansjack wrote:
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!


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 12:32 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
Disassembling the output from the original source gives:
Code:
Disassembly of section .text:
...
    4004:       8b 25 00 40 00 00       mov    0x4000,%esp
Disassembling the output with iansjack's modification gives:
Code:
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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 12:59 pm 
Offline
Member
Member

Joined: Wed May 02, 2018 1:26 pm
Posts: 55
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.


Top
 Profile  
 
 Post subject: Re: Link resulting in malfunctioning OS
PostPosted: Wed May 23, 2018 2:08 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: bemanifan, Majestic-12 [Bot] and 62 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group