gcc specs file generation

[Carl Miller <chaz at energoncube dot net>]

Hi, folks.  I'm looking to add uClibc support to Dan's crosstool.  Prior
projects here have used a system called buildroot to make uClibc-enabled
toolchains, so I've been looking at how buildroot does it.  Much to my
dismay, buildroot patches the binutils and gcc sources in ways that break
non-uClibc builds.  This is unacceptable because I'm trying to keep a
clean single source tree from which I can build multiple targets (BTW, Dan,
I've just about got a patch that lets crosstool share a single unpacked
source tree across multiple target builds, lemme know if you're interested).
So I'm going through the patches and trying to understand them and modify
them so that both uClibc and non-uClibc toolchains build correctly from the
same source tree.

They seem to fall into three categories:
1) Keeping the tools from using native stuff (headers, libraries,
   startfiles, etc.)  My current take is that this is residue from the
   less-enlightened process by which buildroot builds the toolchain, and
   crosstool has already solved this by cleaner means.  Barring failures
   that can't be overcome any other way, I plan to discard these patches
   entirely.
2) The dynamic linker.  uClibc wants a different dynamic linker than
   other targets.  Buildroot patches binutils bfd files and gcc config
   files to point to uClibc's dynamic linker everywhere.  Unfortunately,
   it does so without conditionalizing anything.  More on this one in
   just a moment; this is the one I'm focusing on right now.
3) There's one miscellaneous patch I haven't looked at much yet, but the
   comment says "Prevent gcc from using the unwind-dw2-fde-glibc code".
   I'm ignoring that one for now, but if somebody has some clue what it's
   about, and cares to enlighten me, I'm eager to listen.

So, dynamic linker.  As was brought up in today's thread, the dynamic
linker given in binutils bfd is generic, and generally gets overridden by
gcc, which knows more specific information for the particular target.  So
I'm thinking I can just discard the patch that alters the default dynamic
linker in binutils.

However, it seems I want gcc to generate a specs file that's aware of the
uClibc dynamic linker, and if configured for a uClibc target, uses it by
default.  So I'm delving into how gcc makes a specs file.  Since my first
intended target is powerpc405-linux-uclibc (which is itself not a valid
canonical target specification -- an issue I'll have to attack soon), I'm
looking at gcc/config/rs6000/sysv4.h, which seems to have most of the
interesting specs file generation stuff for powerpc targets.

Questions:
1) If I create a new *_SPEC definition and add it to the list defined by
   SUBTARGET_EXTRA_SPECS, is that all that's required to add a new entry
   to the specs file?
2) Since it's in the LINK_OS_*_SPEC definitions where the dynamic linker
   gets defined, would be most elegant solution be to create a
   LINK_OS_UCLIBC_SPEC define, have that one give ld the option calling
   out the uClibc dynamic linker, include it as link_os_uclibc: in all
   applicable builds, call it out in LINK_OS_SPEC such that -mcall-uclibc
   works as you'd expect, and if a uClibc target is specifically asked for
   at gcc build time, change link_os_default to point to link_os_uclibc?
   Anyone see any pitfalls or aesthetic objections to this approach?
   Alternate suggestions?
3) How would I go about allowing uClibc to be given as part of a target
   specification, and have that cause the redefinition of link_os_default
   to point at link_os_uclibc?

Thanks!

                               -----Carl

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