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 want to submit the changes for ColdFire v4e.
That's very good news indeed!
GCC's main development branch is currently in stage 3; that
means only regression fixes are being accepted at the moment.
To save time, you may start submitting patches now, but
we'll have to wait until the development of GCC 4.1 resumes
in order to commit them.
Before you submit any patches, a very strong suggestion is to check
out a current version of gcc(or snag a current snapshot), put it into
a local CVS repository and make your changes to that to support
ColdFire v4e, that way you know:
1) That the changes you want to make work against the current compiler
2) Exactly what parts need to change.
This approach will naturally lead you to breaking up the diffs to your
CVS repository into bite-sized pieces, especially if you break up the
checkins to your CVS tree.
I second Peter's suggestion, except that I find it more comfortable
to skip the local CVS part and go the "linux kernel way".
I tend to apply my patches to a local snapshot (or CVS checkout) of
GCC, keeping the vanilla copy around for diffing.
When you have many patches over the same files, sometimes two patches
have overlapping parts and need to be applied in a particular order.
When I want to change something, I first revert overlapping patches.
This modus-operandi requires much care, but it gives you greater
flexibility than CVS does and helps you keep the changes .
When you submit several patches, they may be reviewed and approved
out-of-order. Some patches will have to be reworked and resubmitted,
along with an updated ChangeLog.
So I prefer to keep patches in this higher-level format (diff +
ChangeLog + patch discussion) which also lets you make simple
fixes by hacking the diff hunks.
Sometimes you're lucky and most patches apply cleanly to several
GCC versions at once, so you don't have to synchronize your
changes with several branches or repositories.
Does m68k-linux have some special requirements such
as tweaks to the ELF format for shared-library support?
Since PIC support for m68k uses a mode-6 variant to acheive 32-bit
register offset addressing, and ColdFire doesn't support that
addressing mode, then changes needed to be made for PIC addressing
support.
This would be an m68k.md/m68k.c change only, wouldn't it?
Not something that would affect the binary format...
uClinux required that FLAT file format and -mid-shared-library
mess to support shared libraries with UNIX semantics without
an MMU.
The uClinux target has *many* such tricks and thus it's
been made a separate target.
I'd suggest a new target (--target=coldfire-linux) just to seperate
the changes and make it much easier to make sure that you don't break
m68k-linux.
Without seeing what changes he made, I'm not really sure what
would be the best option...
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.
C Jaiprakash, could you please send us your patches for
a first look? No need to polish them up...
This will dovetail with the add-on in glibc to support
ColdFire as well...
Couldn't glibc just use __mcoldfire__ to take care of ColdFire
peculiarities? I'd expect most of the m68k parts to be usable
on ColdFire.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/