Re: New port m32r-linux

[Doug Evans <dje at transmeta dot com>]

Hans-Peter Nilsson writes:
 > > Kazuhiro Inaoka writes:
 > >  > Would you tell me the process of porting new targets if there are any
 > >  > policies?
 > 
 > No policies except talking to the vendor. :-)

Heh.

 > >  > Do we need to keep the compatiblity of m32r-linux relocations with m32r-elf?
 > 
 > Don't change the meaning of the relocations.  Arrange to add new
 > ones instead.  (A good tome to work out the unclear details
 > about R_M32R_26_PCREL, methinks.  See the comment at the entry
 > in m32r_elf_howto_table.

I _think_ the issue there only arises when using REL and branch relaxing.

 > On Wed, 18 Jun 2003, Doug Evans wrote:
 > 
 > > Having m32r-elf.o be incompatible with m32r-linux.o would be a
 > > mistake.  Don't go there.  They must be compatible.
 > 
 > Why so?  I'm coping fine with CRIS.  As Nick pointed out, some
 > detail must be worked out to make them non-linkable of course.
 > Or maybe you just refer to the reloc semantics; I agree then.

My main concern is having m32r-elf and m32r-linux incompatible
only because no one went to the effort to make them be compatible
when such effort was possible.  It bugs me when two tools
could have worked nicely together but don't.

Certainly if there are justifyable ABI changes that can't be made
in an upward compatible manner then I'd say let's not tie m32r-linux's
hands just to remain compatible with older code, but we're not there yet. :-)
Ok, so I amend my "must remain compatible" opinion to "must remain
compatible unless one can acceptably justify any incompatibility".
And for completeness' sake, this goes for the whole ABI
(calling conventions, struct layouts, argument passing, relocations, etc.).