This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with gcc-3.3.2 for ARM


Aitor Garcia wrote:

I think I am missing something.
If arm-elf (linked against newlib) takes less space
than arm-linux (linked against glibc) what's the point in
using
arm-linux ?.

The arm-linux target is a ARM-system which uses Linux as its opsys.

 The arm-elf (as default) target is a ARM-system which
uses the Angel-monitor firmware on the target board.

 In the 1st case the apps communicate through the Linux
kernel (syscalls) with the hardware, in the 2nd case with
the monitor services ('traps' etc.)

 But generally the glue routines (low-level I/O, memory handling
etc.) could also be for something 'local', but in the arm-elf case
they are integrated into the standard C library which is
basically wrong. In the Linux case integrating them to the
C library is then right because the interface between Linux/ARM
and the application has been standardized. As the 'elf' could hint,
the target one is aiming to, maybe isn't very 'real'...

 The 'glue' parts in newlib could really be for Linuces too. There
is a port for SVR3/i386 (in 'newlib/libc/sys/sysvi386') but not
anything similar for any Linux. The Linux/x86 port in newlib is
something really weird.  Anyway it should be possible to extend
those '*-elf' ports in newlib for their equivalent '*-linux' targets
by simply providing those glue libraries for these. But surprisingly
no public tries has been seen... I did this for SVR4/x86/ELF, the
existing SVR3/x86/COFF port was a very good starting point because
these are quite similar what becomes to the startups etc. Meanwhile
trying to find out the structure in the Linux-syscalls was much harder,
the Linux-startup in glibc expects something from glibc, there aren't
so much docs for Linux as there are for the SVR4 ABI and such... So
porting newlib for the mostly undocumented Linux (at least when I tried
these things) can be very hard unless one is one of the glibc-developers.

I suppose that those using arm-elf
will have to pay a toll for an executable that does
the same but occupies much
less space. Otherwise, everyone would use arm-elf.

Yes, it is true that using newlib for arm-elf with glue routines for arm-linux could enable one to produce simple apps for Linux/ARM. But this really means 'simple', getting a C library for Linux which is based on newlib, ie. reinventing everything which is now included into glibc, will be a huge task. For instance there aren't much network support in newlib, not much termcap/terminfo, curses etc. usual Unix 'text-based' apps support either... Getting the "Hello World" running doesn't help much.

Which are the pros and cons of using arm-elf ?.

Instead of 'arm-aout', 'arm-coff' or 'arm-pe' or what?


The board I will use will be running linux.

Then your C library choices can be glibc or the uclibc if the ucLinux is also acceptable... Other surely know more about the alternatives for glibc with Linux/ARM, if there really are any. Maybe ucLinux is one more alternative for Linux with its own kernel, C library and such...

I may choose either an atmel at91rm9200-dk board
(processor: arm920t) or
a sharp lh7a400 (processor: arm922t)
Both boards can handle up to 64MB of SDRAM.

What would you recommend me to use arm-linux or
arm-elf ?.

You already froze your choice to be Linux instead of a no-opsys board. Or not ucLinux or something else...

 Maybe you should ask whether NetBSD/ARM could be better than Linux/ARM,
they both are for embedded-Unix-like systems... Just check what NetBSD
nowadays supports in ARM boards and if there are any comparisons between
Linux and NetBSD for their footprints, ie. which one requires less space
in some purposes... Ok, 'http://www.netbsd.org' will lead you to the NetBSD
pages and basically NetBSD can called as 'real Unix' because the Berkeley
guys (like Bill Joy, the writer of many Unix tools like 'vi') have
influenced Unix so much, meanwhile Linux is only one Unix-clone more,
just like Mark Williams 'Coherent', Whitesmiths 'Idris' etc. were long
before it... So asking whether Unix could be better than Linux in your case
is also reasonable. In the late 80's and early 90's people used to do
similar things with 'embedded' and 'real-time' Unices as what is done with
Linux nowadays... I remember some German company using NetBSD instead of
Linux in their network-controlled laser printer recently. Hmmm, what opsys
was used in that yankee TiVo "hard-disk video recorder", wasn't it something
else than Linux?

 Anyway I would like to see some comparisons between Linux/ARM and NetBSD/ARM
in the embedded cases...

Cheers, Kai




------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]