This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Newbie: How to support new processor architecture


 --- Nick Clifton <nickc@cambridge.redhat.com> schrieb: > 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...

COFF is currently necessary for compatibility, but somewhere further
down in the TODO list is the support for ELF.

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

Hm, that brings me to another idea which I'm asahmed not having had in
the first place: Why not repeatedly import the local copy of the
"external" source tree into the vendor branch of my local repository?
This would be very similar to fetching new snapshots and import them,
as I described above. CVS would help me with the merge then. I'll try.

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

Since I don't know yet what all the new files will be, I guess I wait
with the form until later, ok?

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

But, if I do an objdump on the output file from gas, it shows that some
symbols are declared weak. Since gas output is already COFF, I assumed
that COFF supported weak symbols -- at least the information makes it
into the COFF file somehow. What else is needed?

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

The V850 also uses signed displacements, so I'll probably be able to
find out how to deal with the situation that the base pointer does not
point to the start of the static data area. However, it seems that
there are separate relocation types for each base register (i.e. gp and
ep), which would lead to an enormous number of relocation types in my
case, since I can have a dozen base registers in the E1 if I like. I
don't think I'll want to handle it that way.

Cheers
Stefan


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher für Ihre E-Mails? - http://premiummail.yahoo.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]