Trouble building cross-compiler i686-pc-linux-gnu => mipsel-elf

[Ralf Jahr]

Hi!

Brian Dessent schrieb:
> Ralf Jahr wrote:
> 
>> This works without errors or warnings but... I do not understand what I
>> did. What does "-T nullmon.ld" mean? What determines which *.ld-file I
>> must use? May be you can help me with this...
> 
> -T selects a linker script, which controls how sections are laid out in
> memory and so on.
> 
> I think the real question that you need to answer is why do you care
> about linking?  the *-elf targets are bare-metal, meaning no operating
> system.  Thus you need to fill in a lot of blanks in order to produce
> anything useful -- board-specific things like linker scripts, syscall
> stubs, and so on.  What you're doing at the moment is probably using the
> empty stubs in libgloss in conjunction with a generic linker script
> (nullmon probably means a hardware monitor over null serial cable),
> which means this binary you are producing can do no useful work at all
> because every syscall is just a stub that returns -1 with errno=ENOSYS. 
> For example if you wanted to be able to see the result of printf you'd
> have to write a stub that maps the write syscall to the serial port or
> LCD of the board.
> 
> So if you have an actual embedded system that you want to run these
> binaries on, then go to its vendor and get the BSP (board support
> package) for that board, which should provide all the necessary items:
> startup code, linker script, syscall stubs, whatever.  If you don't have
> a specific board that you're using then why do you care about linking? 
> The output will be useless without those things anyway.  Compiling with
> -c or -S should work without having to worry about any of this, it's
> just linking that requires these details of the hardware.

I want to thank you all, I learned a lot yesterday. My mipsel-compiler 
is working now and I can do what I want to do with it. Linking is also 
quite important because if I use objdump now I can on the one hand also 
see the included functions and on the other hand get information about 
the machine code which has been generated. Sometimes it is quite 
different from the generated assembly (e.g. div by zero checks, function 
inlining etc.).

Bye

Ralf