summaryrefslogtreecommitdiff
path: root/bfd/PORTING
diff options
context:
space:
mode:
authorRichard Henderson <rth@redhat.com>1999-05-03 07:29:11 +0000
committerRichard Henderson <rth@redhat.com>1999-05-03 07:29:11 +0000
commitaa2289c2a3faf0f198e47943dcb29e0c16223be8 (patch)
tree1af963bfd8d3e55167b81def4207f175eaff3a56 /bfd/PORTING
downloadbinutils-redhat-aa2289c2a3faf0f198e47943dcb29e0c16223be8.tar.gz
Initial revision
Diffstat (limited to 'bfd/PORTING')
-rw-r--r--bfd/PORTING83
1 files changed, 83 insertions, 0 deletions
diff --git a/bfd/PORTING b/bfd/PORTING
new file mode 100644
index 0000000000..c8bfd77b96
--- /dev/null
+++ b/bfd/PORTING
@@ -0,0 +1,83 @@
+ Preliminary Notes on Porting BFD
+ --------------------------------
+
+The 'host' is the system a tool runs *on*.
+The 'target' is the system a tool runs *for*, i.e.
+a tool can read/write the binaries of the target.
+
+Porting to a new host
+---------------------
+Pick a name for your host. Call that <host>.
+(<host> might be sun4, ...)
+Create a file hosts/<host>.mh.
+
+Porting to a new target
+-----------------------
+Pick a name for your target. Call that <target>.
+Call the name for your CPU architecture <cpu>.
+You need to create <target>.c and config/<target>.mt,
+and add a case for it to a case statements in bfd/configure.host and
+bfd/config.bfd, which associates each canonical host type with a BFD
+host type (used as the base of the makefile fragment names), and to the
+table in bfd/configure.in which associates each target vector with
+the .o files it uses.
+
+config/<target>.mt is a Makefile fragment.
+The following is usually enough:
+DEFAULT_VECTOR=<target>_vec
+SELECT_ARCHITECTURES=bfd_<cpu>_arch
+
+See the list of cpu types in archures.c, or "ls cpu-*.c".
+If your architecture is new, you need to add it to the tables
+in bfd/archures.c, opcodes/configure.in, and binutils/objdump.c.
+
+For more information about .mt and .mh files, see config/README.
+
+The file <target>.c is the hard part. It implements the
+bfd_target <target>_vec, which includes pointers to
+functions that do the actual <target>-specific methods.
+
+Porting to a <target> that uses the a.out binary format
+-------------------------------------------------------
+
+In this case, the include file aout-target.h probaby does most
+of what you need. The program gen-aout generates <target>.c for
+you automatically for many a.out systems. Do:
+ make gen-aout
+ ./gen-aout <target> > <target>.c
+(This only works if you are building on the target ("native").
+If you must make a cross-port from scratch, copy the most
+similar existing file that includes aout-target.h, and fix what is wrong.)
+
+Check the parameters in <target>.c, and fix anything that is wrong.
+(Also let us know about it; perhaps we can improve gen-aout.c.)
+
+TARGET_IS_BIG_ENDIAN_P
+ Should be defined if <target> is big-endian.
+
+N_HEADER_IN_TEXT(x)
+ See discussion in ../include/aout/aout64.h.
+
+BYTES_IN_WORD
+ Number of bytes per word. (Usually 4 but can be 8.)
+
+ARCH
+ Number of bits per word. (Usually 32, but can be 64.)
+
+ENTRY_CAN_BE_ZERO
+ Define if the extry point (start address of an
+ executable program) can be 0x0.
+
+TEXT_START_ADDR
+ The address of the start of the text segemnt in
+ virtual memory. Normally, the same as the entry point.
+
+TARGET_PAGE_SIZE
+
+SEGMENT_SIZE
+ Usually, the same as the TARGET_PAGE_SIZE.
+ Alignment needed for the data segment.
+
+TARGETNAME
+ The name of the target, for run-time lookups.
+ Usually "a.out-<target>"