Anyone ever install gcc for the ARC microprocessor?

[Kai Ruottu]

Angel Manchado wrote:
> 
> That is what I'm trying to do in order to build gcc for arc-elf,
> and I don't succeed either.
> 
> >  If you build from the FSF-sources, keep them separated until
> > you have checked that the 'utils'-stuff (libiberty, bfd, opcodes,
> > include, readline, intl etc.) doesn't differ too much.
> 
> How do you do that? Using a different --prefix option, perhaps?

 I meaned that trying to combine the binutils-2.11 and gcc-2.95.3
sources shouldn't be done. However I have found out that binutils
and GDB are normally quite well in sync, so combining the snapshots
from the near dates shouldn't be a problem... Perhaps the GCC
snapshots could also be combined with the binutils and GDB when
they are dated closely, but nobody shouldn't assume this working
always, ie. the libiberty, readline, bfd, intl, mmalloc subdirs
being 'frozen' in the FSF  sources (because their last releases
can be years old in the GNU-sites...)
 
> >  I had no troubles at all when testing the build from the untouched
> > binutils-2.11 sources for  the 'arc-elf' target....
> 
> Whith which version of gcc?

 When binutils is in question, no target compiler is involved so
you must mean the host-compiler... So I used the 'production compiler'
in RedHat 6.2, the 'egcs-1.1.2'. I could try the same with gcc-2.95.3
but the host compiler really isn't the problem.

 I built my 'arc-elf' tools last October, and I thought I used
binutils-2.10.1 then, and didn't remember any problems in the build...
However I had a dim memory about some bug report on 'gnu.utils.bug'
or something, so it might have been possible that I had installed
fixes to 2.10.1, then patched the sources to 2.11 and now could think
that I have 'untouched' sources... But I had the 2.10.1 sources still
and couldn't find any fixes for ARC there...

 Anyway I was stupid and replaced the working binutils with the 2.11
version, expecting them to works just as well...

> While trying to build gcc-2.95.3 for arc-elf with binutils-2.11,

  When I looked my '/usr/local/lib/gcc-lib/arc-elf', I saw the dirs
'2.9-edk1.0' and '2.97' there, ie. I built the tools from the RedHat
EDK and the GCC-snapshots in October... This seemed to show there
being something wrong with 2.95.x... If not, I would probably have
built also the '2.95.2' version then...  

> Therefore, I can imagine that you didn't use gcc-2.95.3

  You seem to be absolutely right...

  So I checked gcc-2.95.3 now and the build crashed when trying to
compile the 'lib1funcs.asm', ie. 'libgcc1.S', line 40, saying:

  undefined pseudo op '.cpu'

 It really was undefined in the new 'as'... I had built the previous
binutils in October, (remembering it being the 2.10.1) and now the
update to 2.11 had broken something, the new 'as' didn't recognize
this any more. So my decision was to go back to use binutils-2.10.1...

 When trying to build these, the build gave warnings from LITTLE_ENDIAN
and BIG_ENDIAN redefinitions in 'gas/config/tc-arc.h', then crashed in
'gas/config/tc-arc.c'... This showed that I really hadn't used 2.10.1
and it proved out that I had used the 'fixed binutils-2.10', ie. the
'20000704'-snapshots (when comparing this to 2.10, I found several
useful bugfixes done but generally it was 'binutils-2.10', and even the
2.10.1 release missed some of these bugfixes...).

 Attached are the diffs between 2.10.1 and 20000704 for the 'tc-arc'-
stuff in 'gas/config'.

 When patching with these, I then got 'binutils-2.10.1' built for
'arc-elf'...

 The 2.11 seemed to differ radically from 2.10.1/20000704 what becomes
to the 'gas/config/tc-arc.*', and when the 'pseudo op .cpu' problem
still existed, I decided to use the 20000704-patched binutils-2.10.1
when continuing to try the gcc-2.95.3 build...

 Angel, you must have met the '.cpu' problem when using binutils-2.11,
but is there somewhere a solution to this?

 Then I met the same "junk at end of line: 'ld blink,[fp,4]'" problem
but found a different solution to this... The same file in the
'gcc-2.9-edk-20000221'-sources had seemingly a fix installed, the
gcc-3.0
snapshots too, the diff is also attached here...

 After having met this many bugs in binutils-2.1[01] and gcc-2.95.3, I
would strongly consider building at least one GCC more, I myself tried
also the current '20010521' gcc-3.0 prerelease/snapshots...  They had
the '.cpu' pseudo op in the 'lib1funcs.asm' and crashed with something
else with binutils-2.10.1...

 So the problem seems to be uncompatability in larger scale, the GCC-
sources need binutils which understands the ARC-asm parts in the
sources.
I would see two possible 'in sync' solutions:

1. To use gcc-2.95.3 and the patched binutils-2.10.1. The binutils-2.11
   will crash with the '.cpu'-pseudo op the compiler generates and which
   is present in the 'lib1funcs.asm'. But perhaps there is a solution
and
   binutils-2.11 can be used.

2. To use the gcc-3.0 snapshots and the binutils snapshots (I will check
   this combination), hoping that they have added the '.cpu' recognition
   back...

> On the other hand, please, can you tell me exactly which configure
> options you used, or what is wrong with the following?
> 
>                 --host=i686-pc-linux-gnu \
>                 --target=arc-unknown-elf \

 The only 'cosmetic' issues are these:

 The Unix-idea is to use short names and 'arc-elf' would fit into this,
while the 'arc-unknown-elf' doesn't. If I don't know what to put
to the 'manufacturer', I (normally don't and) leave it out, for me
'nothing' means the 'unknown'.

 The 'unknown' could be replaced with a name which tells about the
default target... If there were a evaluation board named 'archie' or
'bunker' and the toolset would produce executables for it as default,
a target name like 'arc-archie-elf' or 'arc-bunker-elf' could then be
proper... Anyway the purpose for the target name is to fit into the
templates in various 'configure*' or 'config.*' files...

 The second issue is that if you are going to run the tools on
Pentium-I's, AMDs etc., the 'i686' may cause the tools being compiled
for only Pentium-II or newer hosts and they will not run elsewhere...
Using the 'i586' nowadays doesn't forget those 'poor cousins' having
120 - 233 MHz Pentiums still...

 The RedHat-EDK distribution had as its 'x86' library a Pentium-II
optimized glibc and someone then accused RedHat being a liar when
talking about 'x86-support', after vainly trying the generated
executables on a i486/Linux target board...

 Someone recently also wondered why Cygwin doesn't work on AMD
Duron's, and the 'i686' in the current host name in the Cygwin-
distribution came first into my mind... Should the AMD Durons be
i686/PentiumPro/Pentium-II-compatible ?  Is Cygwin really this
much in the Wintel-wagons? (I remember the message being in the
'gnu.gcc.help'-newsgroup)

 If you really use the toolset only in your own 'i686', this CPU-
name isn't a problem...

 When a Sun-server crashes mystically, the phenomen can always be
explained by the 'sunspots' causing it, but what it is when Cygwin
crashes mystically on AMD Duron ?  Amd or Intel, Duron or Sextium -
that's the big question...

> Finally, in an earlier mail to the crossgcc mailing list I have explained
> that the error messages for me now seem to be related with inexistent C
> library headers. Any idea on this?

 If you use newlib and have preinstalled the headers from
'newlib/libc/include' into your '$prefix/$target/include' following the
instructions in the "Using and Porting the GNU Compiler Collection
(GCC)", which you surely have already installed into your system with
the native GCC binaries, and have the manual sources in the '.texi'-
files and possibly also preprocessed '.info' files in the 'gcc' subdir,
there shouldn't be any problems with finding the headers. The
'gcc/INSTALL'
should also have this same info.

 After reading these and if not understanding something or having
troubles
in something, the Cross-GCC FAQ is there to help. It is important to get
the basic GCC docs to be ok first, and they really could be better, the
GCC manual still talks about things which were some limits years ago
(like
that 'libgcc.a' for MIPS can be produced only a MIPS-system...), the
$prefix is not mentioned but the '/usr/local' is used and so on...

 The Chapter/section for the cross-gcc instructions is (can this be a
surprise?) the "Installation / Cross-Compiler".

 This is how I have made cross-gccs for years, but someone could try to
convert me to copy the target headers first into some temporary
directory,
then to point to them using the '--with-headers=', then after the
installation to copy them from the 3rd-party
'$prefix/$target/sys-include'
into the final '$prefix/$target/include'.  As hard I have tried this new
'recommendation', this kind of 'support the entropy' hasn't yet gone
into
my stupid head... On the contrary, I have fixed the main 'Makefile.in'
or/and the 'gcc/cross-make' to look into the '$prefix/$target/include'
for the headers to fix, just as the GCC-manual says the GCC-build
does...
(Please see the definition for GCC_INCLUDE_DIR in the GCC-manual)

 IMHO the jobs to be done before starting to build GCC are the critical
ones in avoiding problems during the build ("Be smart, never start"),
the target headers really will be needed for libgcc, so they must be
preinstalled ... But if you find out that you forgot to do this, just do
it when the error messages arrive, it is not too late even then, just
install the headers and start the make again and be happy...

 So the obvious reason for the missing headers normally is that they
really (and surprisingly!) are missing from $prefix/$target/include,
this may sound really weird but such things happen all the time, just
follow this list... 

 BTW, the 'make all-gcc' is the command to get GCC built, not 'make'.
If you want to produce only the C and C++ compilers, then write:

    make all-gcc LANGUAGES="c c++"

and then

    make install-gcc LANGUAGES="c c++"

to install the C and C++ compilers, then build newlib with the installed
GCC. And finally continue with the libiberty and libstdc++ builds.

 Please note that this was generic info, the ARC-support doesn't include
any startup-routine (crt0.o) or any other target board support (glue
lib)
in newlib, so getting libiberty and libstdc++ built for 'arc-elf' may be
tough...

 Ok, my question is: Is there any example target board support stuff
available for ARC?  Anyone implementing simulator for it and for GDB?

 Having at least some kind of dummy startup would enable one to build
libiberty and libstdc++ too... Richard Kenner seems to be the maintainer
of the GCC/ARC-port, but Peter Targett, <peter.targett@arccores.com>
seems to have maintained the 'gas' port in binutils... The latter could
know something about ARC-assembly and could already have some 'dummy'
crt0.S for ARC... Has anyone asked him?

Cheers, Kai
*** initfini.c	Wed Jan 27 03:43:01 1999
--- /home2/src/gcc-2.9-edk1.0/gcc/config/arc/initfini.c	Wed Oct 11 17:39:08 2000
***************
*** 10,15 ****
--- 10,24 ----
  the Free Software Foundation; either version 2, or (at your option)
  any later version.
  
+ In addition to the permissions in the GNU General Public License, the
+ Free Software Foundation gives you unlimited permission to link the
+ compiled version of this file into combinations with other programs,
+ and to distribute those combinations without any restriction coming
+ from the use of this file.  (The General Public License restrictions
+ do apply in other respects; for example, they cover modification of
+ the file, and distribution when not linked into a combine
+ executable.)
+ 
  GNU CC is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
***************
*** 20,31 ****
  the Free Software Foundation, 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.  */
  
- /* As a special exception, if you link this file with files
-    compiled with GCC to produce an executable, this does not cause
-    the resulting executable to be covered by the GNU General Public License.
-    This exception does not however invalidate any other reasons why
-    the executable file might be covered by the GNU General Public License.  */
- 
  /*  Declare a pointer to void function type.  */
  typedef void (*func_ptr) (void);
  
--- 29,34 ----
***************
*** 138,144 ****
  
  asm ("\n\
  	.section .init\n\
! 	bl.nd __do_global_ctors\
  	ld blink,[fp,4]\n\
  	j.d blink\n\
  	ld.a fp,[sp,16]\n\
--- 141,147 ----
  
  asm ("\n\
  	.section .init\n\
! 	bl.nd __do_global_ctors\n\
  	ld blink,[fp,4]\n\
  	j.d blink\n\
  	ld.a fp,[sp,16]\n\

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tc-arc-diffs.tgz
Type: application/x-gzip
Size: 1700 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20010525/0e1b2a09/attachment.bin>