OS Specific Toolchain noob question

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
justin
Member
Member
Posts: 43
Joined: Sun Jan 11, 2009 2:09 pm

OS Specific Toolchain noob question

Post by justin »

I am following the http://wiki.osdev.org/OS_Specific_Toolchain tutorial. I have built binutils and gcc and now I'm trying to compile some user mode programs to run on my os. Before I built binutils, I set

Code: Select all

TEXT_START_ADDR=0x401000
as was described in the tutorial. However, readelf shows that 0x401094 is the start of the .text section in an executable produced by my new toolchain. What accounts for this discrepancy?

BTW, I haven't built newlib yet and right now I'm manually compiling and linking in some startup code (which is being placed at 0x401094).
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: OS Specific Toolchain noob question

Post by xenos »

Have you checked what is in the 0x94 bytes right before the start of your .text section?
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
jnc100
Member
Member
Posts: 775
Joined: Mon Apr 09, 2007 12:10 pm
Location: London, UK
Contact:

Re: OS Specific Toolchain noob question

Post by jnc100 »

From ld/scripttempl/elf.sc:
TEXT_START_ADDR - the first byte of the text segment, after any headers.

The first bytes of the output file will be the ELF headers, which are then followed by the first section (which is defined to be .text by the ld elf script). This means that, in your case, the text section starts at offset 0x94 in the file, so that if the whole file is loaded aligned to a certain physical page (lets say 0x1000), then you can easily map the text section to the right place by mapping physical 0x1000 -> virtual 0x401000 (and so on until the end of the text section), and this will cause offset 0x94 in the file to be mapped at 0x401094, as expected and all absolute addresses in the code will work as intended.

The other way to do it would to be align the text section on a 0x1000 boundary in the file. Then we would have the elf headers at offset 0 in the file and the .text section at offset 0x1000, mapped to virtual address 0x401000. Whilst this appears to make more sense initially, actually it is wasting a large amount of space in the original file (between the end of the elf headers and the start of the text section).

If you look at the output of readelf -S (or objdump -h) on a elf binary for linux (e.g. /bin/ls) you will see that the text section is also not aligned on a page boundary.

If you wish to find out where to start running code from in the binary then simply check the entry address in the elf headers.

Regards,
John.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: OS Specific Toolchain noob question

Post by bluemoon »

In the end you'll need a program interpreter(program loader) to deal with the program segments and relocate them accordingly, then payload in file offset does not require alignement.
Post Reply