Re: Cross compiling for the 1750A

[~Stack~ <i.am.stack@xxxxxxxxx>]

On 02/07/2012 05:25 AM, Kai Ruottu wrote:
> The assembler tarball had only the assembler sources and some sources
> for testing...
> 
> Generally the '1750a' port in the FSF sources is fuzzy, the 'as1750'
> being both an assembler and a linker and producing of the 'libgcc.a'
> told "not being possible", maybe meaning the same as "not required".
> 
> The alternative 'm1750-coff' target zipfile for Windoze then includes
> a prebuilt C library with headers and library archives. Including a
> prebuilt 'libgcc.a'. Trying to reproduce this on Linux with the just
> built gcc-2.7.2 however crashes in the '__udivmodsi4.o' production :-(
> 
> When checking whether the Windoze-hosted gcc-2.7.2 really had
> succeeded with this, the result was totally identical :
> 
> C:\w1750\src\gcc-2.7.2\temp>\w1750\bin\m1750-coff-gcc -mno-movsi -O2 -I.
> -I.. -I../config -c -DL__udivmodsi4 ../libgcc2.c -o __udivmodsi4.o
> ../libgcc2.c: In function `__udivmodsi4':
> ../libgcc2.c:1695: Unable to find a register to spill.
> (insn:HI 21 18 24 (set (reg/v:HI 24)
>         (mem/s:HI (plus:QI (reg:QI 14 r14)
>                 (const_int 11)))) 87 {movhi+1} (nil)
>     (nil))
> m1750-coff-gcc: Internal compiler error: program cc1 got fatal signal 17
> 
> Ok, the signal # was different... Somehow also this function was made
> because the 'cpp1750.zip' included it in its 'libgcc.a'. Editing its
> production away from the Makefile let a "stripped" libgcc.a being done
> and the gcc-2.7.2 build to go into a happy end...
> 
> Implementing an equivalent to the 'cpp1750.zip' toolchain for a Linux
> host "as it is" should so be fully possible :
> 
> [root@localhost local]# ls -l bin/m1750-coff-*
> -rwxr-xr-x 2 root root 133952  1. helmi  09:49 bin/m1750-coff-ar
> -rwxr-xr-x 2 root root 235744  1. helmi  09:49 bin/m1750-coff-as
> -rwxr-xr-x 2 root root  16682  3. helmi  16:17 bin/m1750-coff-c++
> -rwxr-xr-x 1 root root  22632  1. helmi  09:49 bin/m1750-coff-c++filt
> -rwxr-xr-x 2 root root  16682  3. helmi  16:17 bin/m1750-coff-g++
> -rwxr-xr-x 1 root root  40164  1. helmi  09:49 bin/m1750-coff-gasp
> -rwxr-xr-x 1 root root  65028  3. helmi  16:18 bin/m1750-coff-gcc
> -rwxr-xr-x 2 root root 224564  1. helmi  09:49 bin/m1750-coff-ld
> -rwxr-xr-x 2 root root 142632  1. helmi  09:49 bin/m1750-coff-nm
> -rwxr-xr-x 1 root root 241488  1. helmi  09:49 bin/m1750-coff-objcopy
> -rwxr-xr-x 1 root root 247432  1. helmi  09:49 bin/m1750-coff-objdump
> -rwxr-xr-x 2 root root 133952  1. helmi  09:49 bin/m1750-coff-ranlib
> -rwxr-xr-x 1 root root 121704  1. helmi  09:49 bin/m1750-coff-size
> -rwxr-xr-x 1 root root 121680  1. helmi  09:49 bin/m1750-coff-strings
> -rwxr-xr-x 2 root root 241488  1. helmi  09:49 bin/m1750-coff-strip
> [root@localhost local]# ls -l m1750-coff/bin
> yhteensä 1212
> -rwxr-xr-x 2 root root 133952  1. helmi  09:49 ar
> -rwxr-xr-x 2 root root 235744  1. helmi  09:49 as
> -rwxr-xr-x 1 root root  65028  3. helmi  16:18 gcc
> -rwxr-xr-x 2 root root 224564  1. helmi  09:49 ld
> -rwxr-xr-x 2 root root 142632  1. helmi  09:49 nm
> -rwxr-xr-x 2 root root 133952  1. helmi  09:49 ranlib
> -rwxr-xr-x 2 root root 241488  1. helmi  09:49 strip
> [root@localhost local]# ls -l m1750-coff/lib
> yhteensä 652
> -rw-r--r-- 1 root root   1632 19. elo     1997 crt0.o
> -rw-r--r-- 1 root root  14677 15. touko   1997 crt0.s
> drwxr-xr-x 2 root root   4096  1. helmi  09:47 ldscripts
> -rw-r--r-- 1 root root 128068 19. elo     1997 libc.a
> -rw-r--r-- 1 root root 128068 19. elo     1997 libg.a
> -rw-r--r-- 1 root root  19570 19. elo     1997 libgcc.a
> -rw-r--r-- 1 root root  29078 19. elo     1997 libm.a
> -rw-r--r-- 1 root root 271058 19. elo     1997 libpthread.a
> drwxr-xr-x 2 root root   4096 27. heinä   2004 mmmu
> 
> and so on...
> 
> The '1750a' port doesn't include any 'mmmu' multilib variation etc. But
> seems to be "supported" up to gcc-3.1*, also building from the gcc-3.2.3
> sources will succeed when using '--enable-obsolete' in configure...
> 

Thanks again for your help. I am still running into difficulties but I
am learning a lot by digging into this old code. My co-workers are also
making some progress with the help of Oliver Kellogg (who wrote a good
chunk of this back in the 90's). We are still not there, but I feel we
are slowly getting there.

I am sure that I will post back soon as we are still struggling with this.

Thanks again Andrew and Kai for helping us out!

~Stack~

Attachment: signature.asc
Description: OpenPGP digital signature