OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Apr 19, 2024 11:08 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 12:51 am 
Offline

Joined: Sat Apr 01, 2017 12:26 am
Posts: 2
I originally used a cross compiler, but I curiously compiled the host's g ++ and got the normal output.
What are the benefits of using a cross compiler? :?: :?:

This is a Makefile I wrote.
Code:
.SUFFIXES:.cpp .cpp.o .asm .asm.o

THIS_FILE      := $(abspath $(lastword $(MAKEFILE_LIST)))
FILE_PATH      = $(shell dirname $(THIS_FILE))
OUTPUT         = $(shell basename $(FILE_PATH)).elf

TARGET         = i686-elf.ld

GXX            = g++
NASM         = nasm
QEMU         = qemu-system-x86_64
ECHO         = echo
GDB            = gdb
MAKE         = make
RM            = rm

XXFLAGS      = -fno-rtti -nodefaultlibs -no-canonical-prefixes -nostdlib -ffreestanding -Wall
COMPILE      = -c
OFLAG         = -o
TGTFLAG      = -T
BITS         = -m32
BITS_MODE      = -m32
NFLAGS         = -felf32
FORCE         = -f
PRL            = -j4
MKFLAG         = -C

SRCS_CXX      = $(shell find $(FILE_PATH) -maxdepth 1 -type f -name "*.cpp")
SRCS_ASM      = $(shell find $(FILE_PATH) -maxdepth 1 -type f -name "*.asm")

CXX_OBJS      :=   $(SRCS_CXX:.cpp=.cpp.o)
ASM_OBJS      :=   $(SRCS_ASM:.asm=.asm.o)   

default:
   $(MAKE) $(PRL) $(OUTPUT)

rebuild: clean
   $(MAKE) $(PRL) $(OUTPUT)

clean:
   $(RM) $(FORCE) *.o
   $(RM) $(OUTPUT)

debug:
   $(QEMU) -kernel $(OUTPUT) -s -S &
   ($(ECHO) "target remote 127.0.0.1:1234"; \
      $(ECHO) "symbol-file $(OUTPUT)"; cat) | \
   $(GDB)

$(OUTPUT): $(ASM_OBJS) $(CXX_OBJS)
   $(GXX) $(BITS_MODE) $(ASM_OBJS) $(CXX_OBJS) $(OFLAG) $(OUTPUT) $(TGTFLAG) $(TARGET) $(XXFLAGS)

%.asm.o: %.asm
   $(NASM) $(NFLAGS) $< $(OFLAG) $@

%.cpp.o: %.cpp
   $(GXX) $(BITS_MODE) $(COMPILE) $< $(XXFLAGS) $(OFLAG) $@


This is an ld file provided as barebones on the OSDev wiki. (i686-elf.ld)
Code:
/* The bootloader will look at this image and start execution at the symbol
   designated as the entry point. */
ENTRY(_start)

/* Tell where the various sections of the object files will be put in the final
   kernel image. */
SECTIONS
{
   /* Begin putting sections at 1 MiB, a conventional place for kernels to be
      loaded at by the bootloader. */
   . = 1M;

   /* First put the multiboot header, as it is required to be put very early
      early in the image or the bootloader won't recognize the file format.
      Next we'll put the .text section. */
   .text BLOCK(4K) : ALIGN(4K)
   {
      *(.multiboot)
      *(.text)
   }

   /* Read-only data. */
   .rodata BLOCK(4K) : ALIGN(4K)
   {
      *(.rodata)
   }

   /* Read-write data (initialized) */
   .data BLOCK(4K) : ALIGN(4K)
   {
      *(.data)
   }

   /* Read-write data (uninitialized) and stack */
   .bss BLOCK(4K) : ALIGN(4K)
   {
      *(COMMON)
      *(.bss)
   }

   /* The compiler may produce other sections, by default it will put them in
      a segment with the same name. Simply add stuff here as needed. */
}


This is also a multi-boot header provided as a bare bone. (boot.asm)
Code:
; Declare constants for the multiboot header.
MBALIGN  equ  1<<0              ; align loaded modules on page boundaries
MEMINFO  equ  1<<1              ; provide memory map
FLAGS    equ  MBALIGN | MEMINFO ; this is the Multiboot 'flag' field
MAGIC    equ  0x1BADB002        ; 'magic number' lets bootloader find the header
CHECKSUM equ -(MAGIC + FLAGS)   ; checksum of above, to prove we are multiboot

; Declare a multiboot header that marks the program as a kernel. These are magic
; values that are documented in the multiboot standard. The bootloader will
; search for this signature in the first 8 KiB of the kernel file, aligned at a
; 32-bit boundary. The signature is in its own section so the header can be
; forced to be within the first 8 KiB of the kernel file.
section .multiboot
align 4
   dd MAGIC
   dd FLAGS
   dd CHECKSUM

; The multiboot standard does not define the value of the stack pointer register
; (esp) and it is up to the kernel to provide a stack. This allocates room for a
; small stack by creating a symbol at the bottom of it, then allocating 16384
; bytes for it, and finally creating a symbol at the top. The stack grows
; downwards on x86. The stack is in its own section so it can be marked nobits,
; which means the kernel file is smaller because it does not contain an
; uninitialized stack. The stack on x86 must be 16-byte aligned according to the
; System V ABI standard and de-facto extensions. The compiler will assume the
; stack is properly aligned and failure to align the stack will result in
; undefined behavior.
section .bss
align 4
stack_bottom:
resb 16384 ; 16 KiB
stack_top:

; The linker script specifies _start as the entry point to the kernel and the
; bootloader will jump to this position once the kernel has been loaded. It
; doesn't make sense to return from this function as the bootloader is gone.
; Declare _start as a function symbol with the given symbol size.
section .text
global _start
; extern kernel_main


_start:
   ; The bootloader has loaded us into 32-bit protected mode on a x86
   ; machine. Interrupts are disabled. Paging is disabled. The processor
   ; state is as defined in the multiboot standard. The kernel has full
   ; control of the CPU. The kernel can only make use of hardware features
   ; and any code it provides as part of itself. There's no printf
   ; function, unless the kernel provides its own <stdio.h> header and a
   ; printf implementation. There are no security restrictions, no
   ; safeguards, no debugging mechanisms, only what the kernel provides
   ; itself. It has absolute and complete power over the
   ; machine.

   ; To set up a stack, we set the esp register to point to the top of our
   ; stack (as it grows downwards on x86 systems). This is necessarily done
   ; in assembly as languages such as C cannot function without a stack.
   mov esp, stack_top

   ; This is a good place to initialize crucial processor state before the
   ; high-level kernel is entered. It's best to minimize the early
   ; environment where crucial features are offline. Note that the
   ; processor is not fully initialized yet: Features such as floating
   ; point instructions and instruction set extensions are not initialized
   ; yet. The GDT should be loaded here. Paging should be enabled here.
   ; C++ features such as global constructors and exceptions will require
   ; runtime support to work as well.

   ; Enter the high-level kernel. The ABI requires the stack is 16-byte
   ; aligned at the time of the call instruction (which afterwards pushes
   ; the return pointer of size 4 bytes). The stack was originally 16-byte
   ; aligned above and we've since pushed a multiple of 16 bytes to the
   ; stack since (pushed 0 bytes so far) and the alignment is thus
   ; preserved and the call is well defined.
   extern kernel_main
   call kernel_main

   ; If the system has nothing more to do, put the computer into an
   ; infinite loop. To do that:
   ; 1) Disable interrupts with cli (clear interrupt enable in eflags).
   ;    They are already disabled by the bootloader, so this is not needed.
   ;    Mind that you might later enable interrupts and return from
   ;    kernel_main (which is sort of nonsensical to do).
   ; 2) Wait for the next interrupt to arrive with hlt (halt instruction).
   ;    Since they are disabled, this will lock up the computer.
   ; 3) Jump to the hlt instruction if it ever wakes up due to a
   ;    non-maskable interrupt occurring or due to system management mode.
   cli
.hang:   hlt
   jmp .hang
.end:


This is a simple test code. (kernel_main.cpp)
Code:
class Kernel {
public:
   Kernel() {
      *((char*) 0xb8000) = 'C'; // 'C' into 1, 1
      member = 100;
      *((char*) 0xb8004) = 'M'; // 'M' into 3, 1
   }

   ~Kernel() {
      *((char*) 0xb8002) = 'D'; // 'D' into 2, 1
   }

private:
   int member;

public:
   void run() {
      char* vid = ((char*) 0xb8006);
      char* msg = "welcome!";

      while(*msg) {
         *vid = *msg;

         vid += 2;
         msg++;
      }
   }
};

char kernelObject[sizeof(Kernel)];

inline void* operator new (__SIZE_TYPE__, void* p) throw() { return p; }
inline void operator delete (void*, void*) throw() { }

extern "C" int kernel_main(void) {
   Kernel* kernel = new (kernelObject) Kernel;

   kernel->run();

   while(1);
}


result:
Code:
CeMwelcome!rsion Ubuntu-1.8.2-1ubuntu1)
......


environment:
linux mint 18.1-x86_64 cinnamon
gcc-6.3.0 x86_64-pc-linux-gnu (no cross compiler - build option: ../configure -v --disable-multilib)
- just manually compiled fully. (make all && make install)
nasm (just precompiled deb package)


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 12:55 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5137
Does this help at all?

If not, what question do you have that it doesn't answer?


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 1:29 am 
Offline

Joined: Sat Apr 01, 2017 12:26 am
Posts: 2
Octocontrabass wrote:
Does this help at all?

If not, what question do you have that it doesn't answer?


The point is that the process of creating a cross compiler is too difficult.
I understand that there are many constraints if I do not use it. Though I thought of getting precompiled gcc, I can not use advanced grammar because the version is low. (gcc-4.x.x...)

Also, 64-bit Linux users are experiencing a lot of problems during the process of compiling gcc due to the transitional library called multilib.

If your memory management logic is implemented in MyOS, you can also use stl or boost containers. I think that it can be a process to think about the code that suits it and study it.

Image
Image

These grammatical corrections also exist. I think we need a more colorful and more effective environment for OS development.

So, the bottom line is that if you use something other than a cross-compiler, you're wondering what technical problem you're having. The content on the page can be overcome with many existing utilities.

The process of creating a header file like stddef.h is also a learning process. It is better to use what is already there, but I am wondering if it really helps me.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 1:34 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4594
Location: Chichester, UK
JAYK wrote:
The point is that the process of creating a cross compiler is too difficult.

If you find that too difficult then the more advanced aspects of OS development are really going to try your abilities.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 2:21 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5137
JAYK wrote:
The point is that the process of creating a cross compiler is too difficult.

I'll admit the instructions we have could use some cleaning up, but it's still a lot easier than developing an OS.

JAYK wrote:
Also, 64-bit Linux users are experiencing a lot of problems during the process of compiling gcc due to the transitional library called multilib.

Can you be more specific? If you're having issues at a particular step of building the cross-compiler, we can update the wiki with better instructions to avoid the problem.

JAYK wrote:
So, the bottom line is that if you use something other than a cross-compiler, you're wondering what technical problem you're having. The content on the page can be overcome with many existing utilities.

A cross-compiler is one fix for dozens of problems. Why should you waste your time trying to find a separate fix for each problem when there is one single solution for all of them?

JAYK wrote:
The process of creating a header file like stddef.h is also a learning process. It is better to use what is already there, but I am wondering if it really helps me.

Freestanding headers, including stddef.h, are part of the compiler. Only the compiler developers can write correct freestanding headers.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 11:19 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

JAYK wrote:
What are the benefits of using a cross compiler? :?: :?:


The reasons for a cross-compiler for anything that is "freestanding" are:
  • The host system's compiler doesn't support the target file format or target CPU (e.g. developing ARM software on 80x86)
  • The host system's compiler does not respect "freestanding" and is therefore a broken piece of trash that should never be used at all

The reasons for a cross-compiler for anything that is "hosted" are:
  • You're porting a compiler to your OS (so that you get a native compiler and not a cross compiler), and need a cross-compiler for about 10 minutes to do that.

The other reasons for cross-compilers are:
  • To prove that Unix and GNU tools are a massive "user unfriendly" disaster that should be avoided at all costs.
  • To destroy a beginners motivation before they begin to learn anything useful, by creating an artificial "wall of hassle" that few people are masochist enough to climb when they're starting out.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 4:05 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Hmmn, 'new' member with a name that is pronounced 'J K', on April 1st... asking a question that is pretty flame-bait-y given the history of the forum... Maybe, maybe not. I'm just gonna sit this out and watch.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Sat Apr 01, 2017 5:21 pm 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
It is, of course, perfectly possible to build an OS or other "freestanding" application without using a cross compiler. GRUB is typically built with a "hosted" compiler, as is the Linux kernel.

However, having a cross-compiler does have at least one significant advantage:

It's much more difficult to accidentally "#include" or link against your host OS's libraries (which obviously don't work on the OS you're building). Note that while you might be careful enough never to do this, it's much harder to configure third-party packages' build systems to correctly cross-compile without a cross-compiler, so they're very likely to use the wrong libraries or features your OS doesn't support (yet), like shared libraries, etc.

While I also hate the GNU autotools-based build system with a passion (I battled with it for about two month trying to get Newlib to build as a shared library, eventually giving up and replacing it with a short Makefile), I have to admit that it gets the job done most of the time. It's far easier to get it to cross-compile than certain alternatives... *cough* CMake *cough*

While this doesn't matter too much if you're of the "build absolutely everything yourself from scratch" mindset, but I'm certainly not. I dont have the time or inclination (and sometimes lack the specialist expertise needed) to build everything. I see building an OS as akin to architecting a building. An architect defines the general appearance and structure of the building, sometimes in quite some detail, but rarely would they involve themselves in the details of the electrical systems or plumbing, nor would they specify a non-standard type of brick or come up with their own steel alloy for the structural beams, etc.

I do question the idea that you can get all the userspace components required for (meaningful) self-hosted development (standard library, compiler, debugger, editor/IDE, version control, some form of file management UI, some way of getting code in/out of the OS for backups, etc. etc.) written/ported in "10 minutes" though. My OS started running userspace applications over 2 years ago and I'm still not there, although self-hosting isn't exactly a priority at this stage. A minimal text editor and a basic-but-useful debugger have only come about in the last month or two.

_________________
Image


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Mon Apr 03, 2017 10:31 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7614
Location: Germany
mallard wrote:
While I also hate the GNU autotools-based build system with a passion (I battled with it for about two month trying to get Newlib to build as a shared library, eventually giving up and replacing it with a short Makefile), I have to admit that it gets the job done most of the time. It's far easier to get it to cross-compile than certain alternatives... *cough* CMake *cough*


Sidenote on that: Check out JAWS (an out-of-the-box CMake setup I created) and the M cross environment. The two work together beautifully, if I may say so myself, in cross-compiling MinGW / Windows binaries on Linux under CMake control. Including creating NSIS setup wizards. I admit I haven't tried it on anything OSDev-related. Yes, "getting it right" took some doing, but right now I'm looking at a rather non-trivial piece of software (for which I created JAWS in the first place) that compiles fine on Linux / GCC, AIX / Visual Age, Windows / MSVC, and Linux / MinGW GCC. I've stopped bashing CMake long ago and started applying myself to it. ;-)

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Mon Apr 03, 2017 12:43 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
mallard wrote:
While I also hate the GNU autotools-based build system with a passion... It's far easier to get it to cross-compile than certain alternatives... *cough* CMake *cough*


Not true. CMake does cross-compiling very easy and painless. I even have host-build for tools and cross-build for kernel inside a single CMake environment and it works just fine.

If you have stockholm syndrome because of autotools it's not a reason to bash much better alternatives. Learn them.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Mon Apr 03, 2017 3:04 pm 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
dozniak wrote:
Not true. CMake does cross-compiling very easy and painless. I even have host-build for tools and cross-build for kernel inside a single CMake environment and it works just fine.


Well they say the best way to find out how to do something on the Internet is to proclaim that it's impossible and wait for someone to disprove you...

I'm aware that CMake can be used for cross-compiling, if the developer of the project is careful and doesn't do anything too complex. From the one-or-two CMake-based projects I've used, it seems that it's very common to do things that don't work with cross-compilation, like hard-coded paths or assuming the host and target are the same OS. Maybe I've just come across bad examples.

_________________
Image


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Tue Apr 04, 2017 9:27 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
mallard wrote:
Maybe I've just come across bad examples.


You most probably have.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: why would we use a cross-compiler?
PostPosted: Tue Apr 04, 2017 9:44 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7614
Location: Germany
Similar to how beginners use Makefiles as basically nothing more than a build script with a different name, beginners tend to make their CMakeLists.txt very much less than what CMake allows for.

Partly responsible for that was rather poor early documentation on the CMake project. It's still somewhat lacking in the "best practices" department.

Which is why I came up with JAWS; I found many of the details somewhat difficult to figure out, and thought that people would enjoy getting some of the "bells and whistles" possible with CMake without having to spend much time with trial & error.

_________________
Every good solution is obvious once you've found it.


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

All times are UTC - 6 hours


Who is online

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