This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New target for Coldfire v4e?
Peter Barada wrote:
I tend to apply my patches to a local snapshot (or CVS checkout) of
GCC, keeping the vanilla copy around for diffing.
I don't want to argue the merits of a local CVS repository vs a local
copy, but 'cvs diff -r1.1' will diff against the vanilla version, and
'cvs -q diff -c3p' produces ready to submit patches :)
You mean a single huge patch? How do you split the pieces
apart?
uClinux required that FLAT file format and -mid-shared-library
mess to support shared libraries with UNIX semantics without
an MMU.
Then the answer to your first question is no. The changes are to
m68k.h/m68k.c,m68k.md, as well as the t-linux file and I'd have to go
back and look, but I think maybe one or two others(pretty small
stuff), all in gcc/config/m68k.
Are these changes disruptive for other m68k targets?
gerg@snapgear.com already has a 547x/548x uClinux version(its in the
uclinux CVS tree), using the FLAT file format. I'm assuming it uses
the current m68k-uclinux target.
Last time I checked uClinux's CVS repository and web site, there
were no clues about upcoming v4e support.
It seems this whole development is happening behind a curtain.
NDAs or what?
Without seeing what changes he made, I'm not really sure what
would be the best option...
The more I work in this area, the more I think ColdFire should split
off into its own config directory.
I tend to agree, perhaps sharing some common code. Targets such
as RTEMS and uClinux may want to support both architectures while
retaining consistency in target macros such as TARGET_OS_CPP_BUILTINS.
Besides, adding a new target *can* be approved in stage 3, unless
of course the new code affects other targets. My guess is that
adding v4e support impacts m68k.md and m68k.c *much* more than
the t-linux parts we're discussing, so it won't qualify for 4.0.
I'm sure it won't make it into 4.0.
Perhaps it'd better if it lives as an external patchset for a while,
like many new targets do in their infancy.
I see from the development plan that 4.0 is not going to split off
until early '05, so getting bite-sized patches that reviewers can
understand and approve(but not commit) will make it easier for other
people who want to develop in this area.
The long-term goal may be full-merge, but in the meanwhile you
could get to merge trivial preparatory patches to setup the ground.
Besides, have you already submitted patches for config.sub and
config.guess to the configury project? And what about as/ld changes?
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/