Wed Aug 21 14:33:06 1991 Roland H. Pesch (pesch at cygint.cygnus.com)
authorRoland Pesch <pesch@cygnus>
Wed, 21 Aug 1991 21:37:39 +0000 (21:37 +0000)
committerRoland Pesch <pesch@cygnus>
Wed, 21 Aug 1991 21:37:39 +0000 (21:37 +0000)
* Makefile.in, awkscan-ip, awkscan-p, intobfd,
libbfd.h, libcoff.h, tolibcoff; new bfd-in.h, libbfd-in.h,
libcoff-in.h: (a) use separate files for invariant parts of bfd.h,
libbfd.h, and libcoff.h; (b) in generated parts of same, use less
obtrusive marks indicating .c origins.

* bfd.texinfo: generalize most references to linker

bfd/ChangeLog
bfd/Makefile.in
bfd/awkscan-ip
bfd/awkscan-p
bfd/bfd.texinfo
bfd/intobfd
bfd/tolibbfd
bfd/tolibcoff

index d31bd0f..c5c89dd 100644 (file)
@@ -1,3 +1,13 @@
+Wed Aug 21 14:33:06 1991  Roland H. Pesch  (pesch at cygint.cygnus.com)
+
+       * Makefile.in, awkscan-ip, awkscan-p, intobfd,
+       libbfd.h, libcoff.h, tolibcoff; new bfd-in.h, libbfd-in.h,
+       libcoff-in.h: (a) use separate files for invariant parts of bfd.h,
+       libbfd.h, and libcoff.h; (b) in generated parts of same, use less
+       obtrusive marks indicating .c origins.
+
+       * bfd.texinfo: generalize most references to linker
+
 Tue Aug 20 15:18:02 1991  Roland H. Pesch  (pesch at cygint.cygnus.com)
 
        * Makefile.in: include core.p in PROTOS (building better bfd.h)
index 042195f..1f91491 100644 (file)
@@ -242,13 +242,13 @@ IPROTOS = libbfd.ip cache.ip
 headers : $(PROTOS) $(IPROTOS)
        # Rebuild prototypes in bfd.h
        mv $(BFD_H) $(BFD_H).old
-       sed -f $(srcdir)/intobfd $(BFD_H).old > $(BFD_H)
+       sed -f $(srcdir)/intobfd $(srcdir)/bfd-in.h > $(BFD_H)
        # and libbfd.h
        mv $(srcdir)/libbfd.h libbfd.h.old
-       sed -f $(srcdir)/tolibbfd libbfd.h.old >$(srcdir)/libbfd.h
+       sed -f $(srcdir)/tolibbfd $(srcdir)/libbfd-in.h >$(srcdir)/libbfd.h
        # and libcoff.h
        mv $(srcdir)/libcoff.h libcoff.h.old
-       sed -f $(srcdir)/tolibcoff libcoff.h.old >$(srcdir)/libcoff.h
+       sed -f $(srcdir)/tolibcoff $(srcdir)/libcoff-in.h >$(srcdir)/libcoff.h
 
 
 texinfo:
index 01e3c05..73bd61f 100755 (executable)
@@ -1,8 +1,8 @@
-# NOTE: BEGIN pattern gives errors if other than 1st line; 
-# END ditto if other than last.
-BEGIN { print "/* ------------------------------START FROM " FILENAME "*/" }
+# Awk filter, 1st filter for BFD internal prototype file extraction
 #
 # keep /*proto-internal blocks
 /^\/\*proto-internal\*/,/^\*\/|^\*-\*\//
 #
-END { print "/* --------------------------------END FROM " FILENAME "*/\n" }
+# Apparent bug in sed can discard last line in some situations; therefore
+# make last line harmless.
+END { print "\n" }
index f7240dd..c7fe79f 100755 (executable)
@@ -1,8 +1,8 @@
-# NOTE: BEGIN pattern gives errors if other than 1st line; 
-# END ditto if other than last.
-BEGIN { print "/* ------------------------------START FROM " FILENAME "*/" }
+# Awk filter, 1st filter for BFD prototype file extraction
 #
 # keep /*proto blocks
 /^\/\*proto\*/,/^\*\/|^\*-\*\//
 #
-END { print "/* --------------------------------END FROM " FILENAME "*/\n" }
+# Apparent bug in sed can discard last line in some situations; therefore
+# make last line harmless.
+END { print "\n" }
index 23cf28b..d8ce6f5 100755 (executable)
@@ -226,19 +226,19 @@ representation internally.  This means that the BFD back ends
 cannot maintain all possible data richness through the transformation
 between external to internal and back to external formats.
 
-This limitation is only a problem when using the linker to read one
- format and write another. Each BFD back end is responsible for
+This limitation is only a problem when an application reads one
+format and writes another.  Each BFD back end is responsible for
 maintaining as much data as possible, and the internal BFD
 canonical form has structures which are opaque to the BFD core,
 and exported only to the back ends. When a file is read in one format,
-the canonical form is generated for BFD and the linker. At the
+the canonical form is generated for BFD and the application. At the
 same time, the back end saves away any information which may otherwise
 be lost. If the data is then written back in the same format, the back
 end routine will be able to use the canonical form provided by the
 BFD core as well as the information it prepared earlier.  Since
 there is a great deal of commonality between back ends, this mechanism
 is very useful. There is no information lost for this reason when
-linking big endian COFF to little endian COFF, or from @code{a.out} to
+linking or copying big endian COFF to little endian COFF, or @code{a.out} to
 @code{b.out}.  When a mixture of formats is linked, the information is
 only lost from the files whose format differs from the destination.
 
@@ -259,11 +259,11 @@ Information on target machine architecture, particular implementation
 and format type are stored on a per-file basis. Other information
 includes a demand pageable bit and a write protected bit.  Note that
 information like Unix magic numbers is not stored here---only the magic
-numbers' meaning, so a @code{ZMAGIC} file would have both the demand pageable
-bit and the write protected text bit set.
-
-The byte order of the target is stored on a per-file basis, so that big-
-and little-endian object files may be linked with one another.
+numbers' meaning, so a @code{ZMAGIC} file would have both the demand
+pageable bit and the write protected text bit set.  The byte order of
+the target is stored on a per-file basis, so that big- and little-endian
+object files may be linked with one another.
+@c FIXME: generalize above from "link"?
 
 @item sections
 Each section in the input file contains the name of the section, the
@@ -286,13 +286,9 @@ Normal global and simple local symbols are maintained on output, so an
 output file (no matter its format) will retain symbols pointing to
 functions and to global, static, and common variables.  Some symbol
 information is not worth retaining; in @code{a.out} type information is
-stored in the symbol table as long symbol names. 
-@c FIXME: is the enclosed text linker-specific?
-This information would
-be useless to most COFF debuggers and may be thrown away with
-appropriate command line switches. (The GNU debugger @code{gdb} does
-support @code{a.out} style debugging information in COFF).
-@c end linker-query FIXME
+stored in the symbol table as long symbol names.  This information would
+be useless to most COFF debuggers; the linker has command line switches
+to allow users to throw it away.
 
 There is one word of type information within the symbol, so if the
 format supports symbol type information within symbols (for example COFF,
index 0593e82..b256f4b 100755 (executable)
@@ -1,12 +1,11 @@
-/---------------START FROM/,/---------------END FROM/d
-/\/\* FROM archive.c\*\//r archive.p
-/\/\* FROM archures.c\*\//r archures.p
-/\/\* FROM bfd.c\*\//r bfd.p
-/\/\* FROM core.c\*\//r core.p
-/\/\* FROM format.c\*\//r format.p
-/\/\* FROM libbfd.c\*\//r libbfd.p
-/\/\* FROM opncls.c\*\//r opncls.p
-/\/\* FROM reloc.c\*\//r reloc.p
-/\/\* FROM section.c\*\//r section.p
-/\/\* FROM syms.c\*\//r syms.p
-/\/\* FROM targets.c\*\//r targets.p
+/\/\*:archive.c\*\//r archive.p
+/\/\*:archures.c\*\//r archures.p
+/\/\*:bfd.c\*\//r bfd.p
+/\/\*:core.c\*\//r core.p
+/\/\*:format.c\*\//r format.p
+/\/\*:libbfd.c\*\//r libbfd.p
+/\/\*:opncls.c\*\//r opncls.p
+/\/\*:reloc.c\*\//r reloc.p
+/\/\*:section.c\*\//r section.p
+/\/\*:syms.c\*\//r syms.p
+/\/\*:targets.c\*\//r targets.p
index 157f65a..ef9531e 100755 (executable)
@@ -1,4 +1,4 @@
 /---------------START FROM/,/---------------END FROM/d
-/\/\* FROM libbfd.c\*\//r libbfd.ip
-/\/\* FROM cache.c\*\//r cache.ip
-/\/\* FROM reloc.c\*\//r reloc.ip
+/\/\*:libbfd.c\*\//r libbfd.ip
+/\/\*:cache.c\*\//r cache.ip
+/\/\*:reloc.c\*\//r reloc.ip
index 8a380de..548c8ba 100755 (executable)
@@ -1,2 +1 @@
-/---------------START FROM/,/---------------END FROM/d
-/\/\* FROM coffcode.h\*\//r coffcode.p
+/\/\*:coffcode.h\*\//r coffcode.p