OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 3:03 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: How do you solve the order problem when you link the .o file
PostPosted: Mon Oct 11, 2021 12:03 am 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
I often have linking problems, when I build a project with multiple static libraries. When I am going to link the .o files. Then, I found this problem that is if I change the .o files' order, I won't correctly run this kernel. Later, I searched a lot of materials, and I found this:
Quote:
On Unix-like systems, the traditional behavior of compilers and linkers
is to search for external functions from left to right in the object files
specified on the command line. This means that the object file which
contains the definition of a function should appear after any files which
call that function.

Most current compilers and linkers will search all object files, regardless
of order, but since not all compilers do this it is best to follow the
convention of ordering object files from left to right.


The link instruction are:
Code:
1. ld -nostdlib -T link.lds -o kernel.elf print_amd64.o main.o kernel.o trapa.o trap.o
2. ld -nostdlib -T link.lds -o kernel.elf kernel.o main.o trapa.o trap.o print_amd64.o

objcopy -O binary kernel.elf kernel.bin

dd if=kernel.bin of=boot.img bs=512 count=100 seek=6 conv=notrunc

qemu-system-x86_64 -cpu Skylake-Server -m 512 -hda boot.img -boot d

The first ld instruction is the right and the second one is wrong. In this case, I can certainly change this order of the .o files to make it link correctly. But I use the makefile to compile the huge system containing a lot of files. It is pretty hard to command the makefile to compile each file in order. Do you have any idea to solve this problem?


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 11:25 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
So what is the problem with the second command line? You have not actually said what happens when you use it, only that it doesn't work, which isn't a problem report. But you do use objcopy to remove the ELF headers, so I am going to assume the problem is the multiboot header not getting to the right place. That's what dedicated sections are for.

The linker treats object files and static libraries specified on command line differently from each other. Object files are always linked in, object files in static libraries are only linked in if referenced by the current set of undefined symbols. The upshot is that you may have to specify the same library multiple times to resolve all dependencies, and that order of libraries matters.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 11:50 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
The multiboot header or is it that the program doesn't know it's start address as the headers have been removed?


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 2:36 pm 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
nullplan wrote:
So what is the problem with the second command line? You have not actually said what happens when you use it, only that it doesn't work, which isn't a problem report. But you do use objcopy to remove the ELF headers, so I am going to assume the problem is the multiboot header not getting to the right place. That's what dedicated sections are for.

The linker treats object files and static libraries specified on command line differently from each other. Object files are always linked in, object files in static libraries are only linked in if referenced by the current set of undefined symbols. The upshot is that you may have to specify the same library multiple times to resolve all dependencies, and that order of libraries matters.

I am so glad that got your response. I am sorry I didn't describe it clearly. Actually, the ld can link the .o files as well, and I can got the .bin file. But after that, when I use qemu to boot the kernel, I found that I can't start it. I searched a lot of materials last night, and at this time, I end up found that this problem occurred by the enter function: start. as long as I put the kernel.o at the first, I can correctly run it in the qemu. I attached all project files here, so that you can test them by yourself. And Plus, If I use the makefile to compile all projects I can't adjust the order when I use the ld to link the files. Since it is the simplest project, When we build a big and complicated kernel, we have to compile a lot of files in each directory. So we hardly are able to arrange the order manually. Do you have an idea to solve this program?


Attachments:
File comment: Project files
trap.zip [35 KiB]
Downloaded 14 times


Last edited by benjixu on Mon Oct 11, 2021 2:44 pm, edited 1 time in total.
Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 2:43 pm 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
iansjack wrote:
The multiboot header or is it that the program doesn't know it's start address as the headers have been removed?

I guess that the CPU can't find the entrance of kernel.asm. I attach all project files here, you can test by yourself. and Plus, If I use the makefile to compile all projects I can't adjust the order when I use the ld to link the files. Since it is the simplest project, When we build a big kernel, we have to make a lot of files in each directory. So we hardly are able to arrange the order manually. Do you have an idea to solve this program?


Attachments:
trap.zip [35 KiB]
Downloaded 13 times
Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 3:09 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Your loader jumps to address 0x200000, but you actually want it to jump to the start of the .text section from kernel.o. When you link your object files in a different order, the .text section from a different object file might end up at that address.

You can change your linker script to always put the .text section from kernel.o first, or you can come up with a new section name for the entry point in kernel.asm and change your linker script to always put that new section first.


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 3:53 pm 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
Octocontrabass wrote:
Your loader jumps to address 0x200000, but you actually want it to jump to the start of the .text section from kernel.o. When you link your object files in a different order, the .text section from a different object file might end up at that address.

You can change your linker script to always put the .text section from kernel.o first, or you can come up with a new section name for the entry point in kernel.asm and change your linker script to always put that new section first.

How can I alter the link script? I have no sense in link script?


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Mon Oct 11, 2021 5:26 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
benjixu wrote:
How can I alter the link script?

Here is one way you could do it:
Code:
...
SECTIONS
{
    . = 0x200000;
    /* make sure the .text section from kernel.o ends up at 0x200000 */
    .text.entry : {
        kernel.o(.text)
    }

    .text : {
        *(.text)
...

(I haven't tested this so it may not be entirely correct.)


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Tue Oct 12, 2021 3:09 pm 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
Octocontrabass wrote:
benjixu wrote:
How can I alter the link script?

Here is one way you could do it:
Code:
...
SECTIONS
{
    . = 0x200000;
    /* make sure the .text section from kernel.o ends up at 0x200000 */
    .text.entry : {
        kernel.o(.text)
    }

    .text : {
        *(.text)
...

(I haven't tested this so it may not be entirely correct.)

Yes, you are correct. And plus, if I want to put the main.o in the second one. How can I do?


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Tue Oct 12, 2021 3:19 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Why do you want to change how main.o is linked?


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Tue Oct 12, 2021 9:15 pm 
Offline

Joined: Sat Oct 02, 2021 10:28 pm
Posts: 11
Octocontrabass wrote:
Why do you want to change how main.o is linked?

I just want to know how do you write the link script.


Top
 Profile  
 
 Post subject: Re: How do you solve the order problem when you link the .o
PostPosted: Wed Oct 13, 2021 2:22 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
https://ftp.gnu.org/old-gnu/Manuals/ld- ... /ld_3.html


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

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], SemrushBot [Bot] and 71 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