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
