This is the mail archive of the mailing list for the GCC project.

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: [uClinux-dev] New cross target for uClinux

On Wednesday 20 August 2003 16:39, David McCullough wrote:

> > I'm cleaning up uClinux patches for GCC to move all uClinux-specific
> > target configuration changes away from the m68k-elf target.
> >
> > Up to now, the whole uClinux toolchain was configured for the m68k-elf
> > target, which is not appropriate since binaries produced by this
> > toolchain are neither really ELF, nor suitable for running on bareboard
> > targets.
> I would disagree with this to some extent.  It does produce elf files,
> along with flat files ;-)

Well, technically the elf2flt hidden into m68k-elf-ld is just a
big kludge ;-)

But in GCC, the *-elf, *-coff and *-aout targets are meant to be used
on bareboard embedded systems. These targets are tipically used along
with newlib.

Since we're using uClinux, our toolchain target should be called
something like m68k-uclinux or perhaps m68k-linux-uclibc (*).

But this is not just a matter of taste. We can't get uClinux specific
changes approved into GCC's mainline until they break the original
m68k-elf target which is used by the ColdFire people.

 (*) I found out that I couldn't easily reuse definitions for m68k-linux in
     GCC's target config, therefore m68k-uclinux appears to be a better fit.

> We use the m68k-elf compiler to build bootloaders and all manner of
> different things (including the kernel which is elf) so it hasn't seems
> like a bad fit IMO.

This is the same of using the 'i386-linux' version of GCC to build the
Linux kernel on a PC. By default, the compiler does whatever is needed
to build common Linux applications, but you can play with the options
to disable linking with standard libraries and dropping the include path,
so that you can build a standalone binary.

To build the kernel and CoLilo, all we'll have to do passing the
-nostdinc and -nostdlib to m68k-uclinux-gcc. We already do so both in the
kernel and in userland Makefiles.

However, the current GCC 3.3.1 is much more friendlier than earlier
versions since it allows you to compile and link simple applications
almost in the usual way:

   m68k-elf-gcc -m5307 hello.c -o hello

> > Since the 'm68k-elf' target has been in use for several years on uClinux,
> > There are far too many places in the uClinux build infrastructure where
> > m68k-elf is assumed and I can't patch them all at the same time. We also
> > need to make the uClinux source base compatible with both the old and new
> > GCC toolchains for some time.
> I would agree with this.  I don't think too many people will switch to
> the new toolchain immediately as the existing toolchain is working fine
> for them.  There are still uClinux people who use the coff tools !

Did uClinux really use COFF in the past? I would never have imagined...

> > I'd like to reduce the impact of the target change by installing GCC with
> > a backwards-compatible prefix (i.e.: m68k-elf-gcc, etc.).
> >
> > I'm also soft-linking /usr/local/m68k-elf to /usr/local/m68k-uclinux to
> > let the compiler find gas and ld properly. I also had to softlink
> > m68k-elf-ar to build libgcc.
> >
> > But I've just realized this thing is requiring too many kludges. Is there
> > something I can do, perhaps in config.gcc, to tell GCC it should be using
> > a different target prefix for binutils and uClibc?
> What is the conflict/delemma within gcc with sticking to m68k-elf ?
> If the changes to gcc are mostly generic,  then we could provide and
> m68k-elf toolchain and a m68k-XXXX toolchain for those that what the
> uclinux targeted compiler I guess.

I can't add the -mid-shared-libary multilib targets in m68k-elf because
these require uClibc. And there are some more uClinux changes that would
mostly displease the current users of unpatched m68k-elf-gcc.

> Alternatively,  we could say the the 2.95 based compiler is m68k-elf and
> the 3.x compiler is whatever,  and until you convert your platform to
> the new compiler it uses the old one.  At least this way one can have
> both the old and new compilers on their system and switch relatively
> easily between them (just a config.arch edit for uclinux users),

Hmmm, not a bad idea. However, GCC already provides a simple way to switch
between different compiler versions. You just need to install the newest
compiler last and use the -V GCC option to force an older version.

  // Bernardo Innocenti - Develer S.r.l., R&D dept.

Please don't send Word attachments -

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