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]

Newbie: How to support new processor architecture


Hi all,

I am currently in the process of adding support for a new processor
architecture to binutils (Hyperstone E1 processors, coff format). As
I'm not intimately familiar with the toolset, I've got a few questions
and hope someone can help me with them:

CVS setup:

I am working with a cvs server here where I keep the sources. I
imported an initial version of the sources (binutils, newlib,
gdb+insight) which I checked out from anoncvs@sources.redhat.com. 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?). I want to commit my changes to my cvs server while
tracking changes made on the main repository at redhat. From the cvs
cederqvist manual I know that one possibility for doing this is to
periodically get the newest sources from redhat and import them into my
cvs repository, thereby creating a separate vendor branch which I can
merge into my modified main trunk. 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?

Integration of my contribution into the public releases:

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? I suppose my contribution will have to be sent as
a patch file. What is the required format of this file? Do I create the
patch with respect to the "newest" sources on the redhat cvs server or
with respect to a certain release? Is there a checklist of what to do
before submitting the patch in order to save time and work for the
maintainers? 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?

Integration of gcc:

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? Should I use a "grand unified" source tree
or should I rather keep gcc separate?

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?

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?

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?

Multiple static base registers:

An application can save code space by reserving several registers to
point to global/static data. This allows more than 8kBytes of static
data without having to use long range offsets in memory access
instructions. I was thinking about how to support this in a
straightforward way and came up with the following idea. Please tell me
if you think this is a stupid or bad idea.

I want the linker to know a number of special section names like .Gx
where x is a register number. If a symbol is located in one of those
sections, the linker puts the corresponding base register number into
each instruction using the symbol. If that works properly, the user can
control base pointer usage in the assembler source and/or in the linker
script.


Thanks for your support
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]