This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: GCC: different OS targets.
- To: brendan@dgs.monash.edu.au
- Subject: [ECOS] Re: GCC: different OS targets.
- From: Bart Veer <bartv@cygnus.co.uk>
- Date: Mon, 23 Aug 1999 14:10:41 +0100
- CC: ecos-discuss@sourceware.cygnus.com
- References: <37C099D3.C0BE0BC5@dgs.monash.edu.au>
- Reply-to: bartv@cygnus.co.uk
>>>>> "Brendan" == Brendan Simon <brendan@dgs.monash.edu.au> writes:
Brendan> There seems to be different builds of egcs/gcc for
Brendan> various Operating Systems (eg. eCos, RTEMS). I
Brendan> predominantly use the powerpc-eabi target. I currently
Brendan> use it with No OS (NOS) on some MPC860 boards but would
Brendan> like to use an OS. Both RTEMS and eCos use EABI as well,
Brendan> so the same compiler should be useable for GCC targeting
Brendan> RTEMS, eCos and NOS.
Unfortunately it is not that simple...
There are a number of areas where the compiler needs to be aware of
the target. The main example is C++ exception handling: the compiler
needs to have access to some per-thread data for this to work, and
the way to do this will vary between targets.
Ideally this sort of thing would be handled at run-time by having the
compiler contain a suitable scripting language interpreter and loading
in a script specific to the desired runtime. That way new target
systems or variations thereof can be accommodated without having to
change the compiler. Implementing this would be a lot of work.
Less ideal would be to have support for several different targets
built into gcc, and select one of them via a command-line switch.
Although I am not a gcc expert, my understanding is that this would
still be a lot of work because it does not match the way gcc works
internally.
The current implementation of gcc involves knowledge of the target to
being built directly into the compiler, which means you need separate
compiler installations for different runtimes. This is certainly
unfortunate, but tolerable for the majority of users.
Nearly all of the effort required will be in the compiler, so the
correct forum for this sort of discussion is the egcs mailing list -
see egcs.cygnus.com. However I doubt that anything will happen unless
somebody either does the work and contributes it, or somebody pays for
the work to be done and contributed.
Brendan> I figure that the -m switch might be appropriate for
Brendan> choosing the operating system. Powerpc has a -mads
Brendan> (amongst others) switch which links the ads crt0.o file
Brendan> and libads via the specs file. Does the specs file only
Brendan> work with the -m switch all will it work with any other
Brendan> swtich ? The -m switch could be used to select the
Brendan> operating system. eg. "-m ads-rtems" or "-m rtems-ads". A
Brendan> separate directory for the OS stuff would be setup in
Brendan> $prefix$target/$os (eg. /usr/local/gcc/rtems/include and
Brendan> /usr/local/gcc/rtems/lib) or maybe $prefix/$target/os/$os
Brendan> (eg. /usr/local/gcc/os/rtems/... or
Brendan> /usr/local/gcc/os/none/...).
The -m switch and the specs file make it easy to control some aspects
of builds, for example the file used for the startup, or the default
include path. It cannot readily control internals of the compiler such
as the implementation of exception handling.
Bart Veer // eCos net maintainer