Re: Newbie: How to support new processor architecture

[Nick Clifton <nickc at cambridge dot redhat dot com>]

Hi Stefan,

> I am currently in the process of adding support for a new processor 
> architecture to binutils (Hyperstone E1 processors, coff format).

If you have the choice, I would recommend ELF over COFF...

> I keep all sources in a unified source tree (is that the right idea
> -- or is ist preferable to have a separate source tree for each
> distribution?).

No, the unified source tree is better.

> I want to commit my changes to my cvs server while tracking changes
> made on the main repository at redhat.

Just to make sure that nobody gets the wrong impression, the sources
do not in any way belong to RedHat, they belong to the Free Software
Foundation.  It is just that RedHat happens to be providing the
hosting facilities for the binutils repository.  It could very well
be some other company or organization that was providing the
facilities.


> That's ok so far, but I was wondering whether it is really necessary
> to get the entire source tree from redhat each time. It would be
> much better if I could just "update" my vendor branch from the cvs
> server at redhat, thereby saving bandwidth and server load on the
> redhat server. How would you do this, is there a recommended way?

One method you may wish to consider is to use two repositories, an
internal one and an external one.  The external one is the binutils
repository at sourceware.redhat.com.  You keep a checked out copy of
this repository on your local machine.  Meanwhile you set up your own,
internal repository and do all of your development work on a checked
out copy of the mainline of this repository.  But - and here is the
tricky bit - you mark all of your changes with some kind of magic text
marker.

Then when the time comes to merge in the latest binutils changes you
update your checked out copy of the external repository.  Then you
manually merge files from the external copy into your internal copy
and then check the internal copy back in to your internal server.

This manual merge can actually be mostly automated.  If the internal
version of a file does not contain any magic markers then it can just
be replaced with the external version.  If the file does contain the
markers you can use a text processing tool to turn the marked areas
into a patch.  Then you replace the internal file with the external
copy and apply the patch.  If the patch applies cleanly you are done,
otherwise you have to back off and call for user intervention.

Since you are developing a new port most of the work you do will be in
new files which will not be affected by the merge process, and the
changes to generic binutils files should be quite small.  Thus the
burden of merging should not be too high.

> My work is meant to be eventually contributed to the public binutils
> releases. Is there anything to be kept in mind now so that I can do
> this easily later on?

Yes - you will need to complete a copyright assignment to the FSF.
(See the form attached at the end of this email).

> I suppose my contribution will have to be sent as a patch file.

Actually we would prefer if you sent it as several patch files, split
on a per-toplevel-directory basis.  (ie one for gas, one for bfd, one
opcodes, etc).  This stops the emails from getting too big.

> What is the required format of this file?

Please use "diff -c3p" to create the patch.  (Or "cvs diff -c3p" if
you are diffing against checked out sources).

> Do I create the patch with respect to the "newest" sources on the
> redhat cvs server or with respect to a certain release?

Please create it with respect the newest sources.

> Is there a checklist of what to do before submitting the patch in
> order to save time and work for the maintainers?

Nope - you send an email to this list and I respond :-)

> Given that I keep my source in a unified source tree, can I send a
> "unified" patch that contains my contributions to all packages in
> the tree or do I have to submit separate patches for each package?

Sorry - you need separate patches for each package.  There are
different mailing lists and different maintainers for each package, so
you will need to get approval from several different people before all
of your work is integrated into the repositories.

> GCC is kept at anoncvs@subversions.gnu.org and not at redhat,
> although the source tree seems to be compatible with the
> binutils/newlib/gdb tree. Are they compatible?

Yes.

> Should I use a "grand unified" source tree or should I rather keep
> gcc separate?

Grand unified.

> Weak symbols:
> 
> I seem to manage weak symbols alright in gas, but not in ld. What does
> it take to support weak symbols in ld? Where do I look for information,
> resp. where does it happen in the source?

The COFF format will not support weak symbols.  Either switch to ELF
or  abandon using weak symbols.

> Relaxing in ld:
> 
> I want to support relaxing in the linker, because that will reduce code
> size in my target architecture. Where do I find information on how this
> works resp. what I have to do to enable it?

The best method is to work by example from another port.  For instance
the SH port has linker relaxing in both its ELF and COFF variants,

> Static base register offsets:
> 
> The target processor has multiple registers that can serve as a base
> pointer for accessing static data using a "register plus constant
> offset" addressing scheme. The offset is signed and can be given in two
> ranges. The shorter range saves code space, but allows distances of
> only -4096..4095 from the base register. Given linker relaxing, I would
> expect the smallest resulting code if the static base register is set
> up to point 4096 bytes "beyond" the start of the static data area, so
> that 8kBytes of static data can be addressed using the short offset
> format. What do I have to do to make this work?

Several other formats also have special base registers.  For instance
the v850 port has the 'ep' and 'gp' registers.  I would suggest
perusing the code for these ports to gain an idea of how to handle the
situation.

Cheers
        Nick

---------------------------------------------------------------------------

request-assign.future:

Please email the following information to fsf-records@gnu.org, and we
will send you the assignment form for your past and future changes.
Please use your full name as the subject line of the message.


[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your snail address here.]





[Which files have you changed so far, and which new files have you written
so far?]





---------------------------------------------------------------------------