Re: New target for Coldfire v4e?

[Peter Barada <peter at the-baradas dot com>]

>> 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.

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 :)

>>>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.

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. 

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.

>> 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...

The more I work in this area, the more I think ColdFire should split
off into its own config directory.

>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.

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.

-- 
Peter Barada
peter@the-baradas.com