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

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

[Ralf Jahr]

Dear list,

I try to build a cross-compiler for a mips-target. My goal is not to run 
the code but to get an idea of how gcc performs optimizations as for 
example modulo scheduling. The target I am actually working with is the 
PISA architecture used by SimpleScalar. This is not supported but 
similar to the mips4 architecture. So far...

I used this tutorial [1] and GCC 4.3.2, binutils 2.18. Compiling the 
binutils and gcc worked fine, it did not throw any errors. You can see 
my log here: [2]

[1] http://wiki.osdev.org/GCC_Cross-Compiler#Step_1_-_Bootstrap
[2] http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php

Well, i assumed that I would get a compiler which can build executables. 
Unfortunately but this does not work; I get the following error message:

/usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld: 
crti.o: No such file: No such file or directory
collect2: ld returned 1 exit status

More logging information can be seen here:

http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php#testing

Should this normally have worked? Do you have any ideas how in can make 
it working or what I did wrong?

Thanks in advance, bye

Ralf

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

[Andrew Haley]

Ralf Jahr wrote:

> I try to build a cross-compiler for a mips-target. My goal is not to run
> the code but to get an idea of how gcc performs optimizations as for
> example modulo scheduling. The target I am actually working with is the
> PISA architecture used by SimpleScalar. This is not supported but
> similar to the mips4 architecture. So far...
> 
> I used this tutorial [1] and GCC 4.3.2, binutils 2.18. Compiling the
> binutils and gcc worked fine, it did not throw any errors. You can see
> my log here: [2]
> 
> [1] http://wiki.osdev.org/GCC_Cross-Compiler#Step_1_-_Bootstrap
> [2] http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php
> 
> Well, i assumed that I would get a compiler which can build executables.
> Unfortunately but this does not work; I get the following error message:
> 
> /usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld:
> crti.o: No such file: No such file or directory
> collect2: ld returned 1 exit status
> 
> More logging information can be seen here:
> 
> http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php#testing
> 
> Should this normally have worked? Do you have any ideas how in can make
> it working or what I did wrong?

crti.o is part of the C library.  You haven't installed a C library, so
your programs won't link.

If you don't need to run your programs, you can simply use the -S option
to gcc to produce source code.

Andrew.

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

[Ralf Jahr]

Hello!

Andrew Haley wrote:
> Ralf Jahr wrote:
> 
>> I try to build a cross-compiler for a mips-target. My goal is not to run
>> the code but to get an idea of how gcc performs optimizations as for
>> example modulo scheduling. The target I am actually working with is the
>> PISA architecture used by SimpleScalar. This is not supported but
>> similar to the mips4 architecture. So far...
>>
>> I used this tutorial [1] and GCC 4.3.2, binutils 2.18. Compiling the
>> binutils and gcc worked fine, it did not throw any errors. You can see
>> my log here: [2]
>>
>> [1] http://wiki.osdev.org/GCC_Cross-Compiler#Step_1_-_Bootstrap
>> [2] http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php
>>
>> Well, i assumed that I would get a compiler which can build executables.
>> Unfortunately but this does not work; I get the following error message:
>>
>> /usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld:
>> crti.o: No such file: No such file or directory
>> collect2: ld returned 1 exit status
>>
>> More logging information can be seen here:
>>
>> http://www.informatik.uni-augsburg.de/~jahrralf/gcc.php#testing
>>
>> Should this normally have worked? Do you have any ideas how in can make
>> it working or what I did wrong?
> 
> crti.o is part of the C library.  You haven't installed a C library, so
> your programs won't link.
> 
> If you don't need to run your programs, you can simply use the -S option
> to gcc to produce source code.

OK, thanks for the inspiration. :-) I got newlibc to compile even 
without being able to generate executables. Then I saw that "make all" 
works with GCC although I thought it would not... Then some steps later 
I can now generate executables and use objdump on them. But I get a 
warning message:

./mipsel-elf-gcc -O3 hello.c -msoft-float -static
/usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld: 
warning: cannot find entry symbol _start; defaulting to 0000000000400050

I think I can live with this. But if I want to use printf I get another 
error:

./mipsel-elf-gcc -O3 hello.c -msoft-float -static

hello.c: In function 'main':
hello.c:16: warning: incompatible implicit declaration of built-in 
function 'printf'
/usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld: 
warning: cannot find entry symbol _start; defaulting to 0000000000400050
/tmp/ccqMFE2F.o: In function `main':
(.text+0xd4): undefined reference to `printf'
collect2: ld returned 1 exit status

Even adding the compiled libc.a does not help: [1]

[1] http://www.informatik.uni-augsburg.de/~jahrralf/liberrors.txt

Do you have any ideas how I can get rid of this error, too?

Thanks again!

Ralf

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

[John Love-Jensen]

Hi Ralf,

When you did...

make install

...where did you install mipsel-elf-gcc to?

And why are you in that directory when you invoke ./mipsel-elf-gcc?  (Not
that you can't do that, but it is somewhat unusual.)

I only ask because GCC does not support being run in the directory in which
it is built, it needs to be installed.

--Eljay

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

[Kai Ruottu]

Ralf Jahr wrote:

> Andrew Haley wrote:
>> Ralf Jahr wrote:
>>> I try to build a cross-compiler for a mips-target.
>>> Well, i assumed that I would get a compiler which can build executables.
>>> Unfortunately but this does not work; I get the following error message:
>>>
>>> /usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld:
>>> crti.o: No such file: No such file or directory
>>> collect2: ld returned 1 exit status
>>
>> crti.o is part of the C library.  You haven't installed a C library, so
>> your programs won't link.
> 
> OK, thanks for the inspiration. :-) I got newlibc to compile even 
> without being able to generate executables.
> I can now generate executables and use objdump on them. But I get a 
> warning message:
> 
> /mipsel-elf-gcc -O3 hello.c -msoft-float -static
> /usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld: 
> warning: cannot find entry symbol _start; defaulting to 0000000000400050
> 
> I think I can live with this. But if I want to use printf I get another 
> error:
> (.text+0xd4): undefined reference to `printf'
> collect2: ld returned 1 exit status
> 
> Even adding the compiled libc.a does not help:
> Do you have any ideas how I can get rid of this error, too?

Ok, you now learned that producing executables requires a C library with
startups... But what is still required is some "real" target for "which"
to produce executables!

The 'mipsel' in the target name is the "cpu/endianess" type, the 'elf'
is only the object format, and these two don't yet define the interfaces
to the target system, its I/O-system, its memory layout, possible
'syscall' (calls to the 'opsys') etc.

The newlib C library has some "glue" libraries for some HW/firmware
systems like the PMON-monitor firmware on a MIPS-board, the 'libpmon.a'
probably was the name for this glue library. Another real target is an
IDT-borad with some IDT-monitor....

There are many ways to tell what that "real target" is, one of these is
to edit a default one into the GCC's 'specs' file. I myself have used
this because mainly producing executables to the MIPS-simulator coming
with the GNU debugger, 'GDB', and this can run apps made for IDT.

The important (edited) rows in my gcc-3.2.3 'specs' are :

--------------- clip ---------------------------------

*endfile:
crtend%O%s crtn%O%s -T idt.ld%s

*link:
%(endian_spec) %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} 
%{mips64} %{bestGnum} %{shared} %{non_shared}

*lib:


*libgcc:
-lgcc

*startfile:
crti%O%s crtbegin%O%s

--------------- clip ---------------------------------

The long row after '*link' may be seen as two rows but there is only one
and then an empty row after each "spec"... Generally only the startfiles
(linked first) and the endfiles (linked last) are defined, the 'libgcc'
too, everything else is in that 'linker script' for the IDT-board,
'idt.ld', also this being provided in an installed newlib for mips*-elf.
The important thing in editing 'specs' is that it has ist own 'strict'
format :

<specname>
<the spec itself>
<empty line>

Those '%s' ("search and parse this") etc things were described
somewhere, the '-T' option for 'ld' should be described in the
linker documents...

When testing the edited 'specs', using a '-v' in the 'compile and link'
command will teach things...  Putting a '-Wl,-verbose' onto it will
then show what happens during the link phase ("verbosely", with all
details)...

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

[Ralf Jahr]

Hi again!

John Love-Jensen schrieb:
> When you did...
> 
> make install
> 
> ...where did you install mipsel-elf-gcc to?
> 
> And why are you in that directory when you invoke ./mipsel-elf-gcc?  (Not
> that you can't do that, but it is somewhat unusual.)
> 
> I only ask because GCC does not support being run in the directory in which
> it is built, it needs to be installed.

Don't worry, I used the directory /usr/cross-mips for deployment (and as 
  $PREFIX during compilation). I run mips-elf-gcc from directory 
/usr/cross-mips/bin and places my hello.c there, too.

OK, to get rid of the lately mentioned errors I used the following 
command to compile hello.c:

./mipsel-elf-gcc hello.c -msoft-float -T nullmon.ld --static

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...

I also updated my "log" of executed statements, may be it helps anybody:

http://www.informatik.uni-augsburg.de/~jahrralf/gcc_working.php

Thanks again and bye bye

Ralf

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

[Brian Dessent]

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.

Brian

Re: 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