Cross compiler cannot find crt0.o / crti.o / crtn.o

[Twicetimes]

Context: I've been following the tutorials on the Osdev wiki. I'm now in a position where I've got the Meaty Skeleton codebase, and I've followed the OS-specific toolchain and Hosted GCC cross-compiler guides, resulting in a set of i686-substrata-* tools.

I also opted for making my own libc rather than using a prebuilt one. For now I've just provided enough of the standard headers so that libgcc builds successfully (as per the guide)

When using i686-substrata-gcc to try to build a simple user space program (literally just int main() { return 0; } ), I receive the following errors:

Code: Select all

/home/martin/opt/substrata/lib/gcc/i686-substrata/6.1.0/../../../../i686-substrata/bin/ld: cannot find crt0.o: No such file or directory
/home/martin/opt/substrata/lib/gcc/i686-substrata/6.1.0/../../../../i686-substrata/bin/ld: cannot find crti.o: No such file or directory
/home/martin/opt/substrata/lib/gcc/i686-substrata/6.1.0/../../../../i686-substrata/bin/ld: cannot find crtn.o: No such file or directory

Ok, the first error makes sense, as I haven't yet made a crt0.o of my own. On the Creating a C library tutorial, it shows a crt0.s source for x86_64.

• 1. Am I correct in assuming that I can't just use that crt0.s example, because my cross toolchain is 32-bit (i686-substrata-*) and not 64-bit (x86_64-substrata-*)?
  2. How would I go about making an x86 version of crt0.s? More than just changing register names and the calling convention?
  3. What is involved in creating an x86_64 version of the cross toolchain?

I'm not sure about the crti.o and crtn.o errors. The skeleton project has built a crti.o and crtn.o in kernel/arch/i386/, but the build scripts don't copy these anywhere. Am I getting confused here by thinking these files are relevant? Is this kernel libc vs userspace libc?

I apologise if my questions make no sense or have blindingly obvious answers. Any guidance is much appreciated.

[heat]

Hi,

First off, why are you trying to make an OS specific toolchain and compiling user programs with the meaty skeleton codebase? Meaty Skeleton can't even switch to user-mode or map memory.

But, to answer your questions:

1 - Correct.

2 - Yes you do need to do more than that. The implementation of crt0 on the wiki does the following:

• - Makes an end to the stack frame linked list ( you don't need to do that )
  - Initializes the standard library ( you do NEED to do this )
  - Call global constructors ( you do NEED to do this )
  - Pass argc and argv to main ( you do NEED to do this )
  - After main returns, call exit with main's return value ( you do NEED to do this ).

You also need to know the calling convention of your target architecture (i386 on your case).

3 - To make an x86_64 version of the toolchain, the steps are very similar to i386's. The wiki actually also has directions to make your custom toolchain able to target x86_64. Beware that if you make your TEXT_ADDR a high address, you will have problems with GCC's default memory models.

[Twicetimes]

Thanks for your answers.

First off, why are you trying to make an OS specific toolchain and compiling user programs with the meaty skeleton codebase? Meaty Skeleton can't even switch to user-mode or map memory.

Fair point. My thinking was that there's no harm in making the custom cross toolchain straight away. I could stick with the generic i686-elf one for a while, but as the tutorials say, that will eventually not be useful enough as it doesn't support user space.

Would you say there's value in sticking with the generic one for a while, while I'm just running kernel mode stuff?

[heat]

Thanks for your answers.

First off, why are you trying to make an OS specific toolchain and compiling user programs with the meaty skeleton codebase? Meaty Skeleton can't even switch to user-mode or map memory.

Fair point. My thinking was that there's no harm in making the custom cross toolchain straight away. I could stick with the generic i686-elf one for a while, but as the tutorials say, that will eventually not be useful enough as it doesn't support user space.

Would you say there's value in sticking with the generic one for a while, while I'm just running kernel mode stuff?

Yeah, there is no harm in using your custom toolchain, as it is only a slightly modified i686-elf target. You certainly wasted a bit of time patching through GCC and Binutils, but you would have to do it someday anyways. You can use your custom target, as long as you don't forget to pass important options such as -fno-builtin and -ffreestanding ( don't forget a linker script too ).

[max]

2 - Yes you do need to do more than that. The implementation of crt0 on the wiki does the following:

• - Makes an end to the stack frame linked list ( you don't need to do that )
  - Initializes the standard library ( you do NEED to do this )
  - Call global constructors ( you do NEED to do this )
  - Pass argc and argv to main ( you do NEED to do this )
  - After main returns, call exit with main's return value ( you do NEED to do this ).

You also need to know the calling convention of your target architecture (i386 on your case).

You usually do not implement all that stuff in the crt0 file. Just implement it in C/C++ and then call that from your crt0 file. It's a part of your libc anyway.

See this and that.