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
This commit is contained in:
parent
90125c8596
commit
dd260c230b
8 changed files with 48 additions and 44 deletions
|
@ -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)
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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" }
|
||||
|
|
|
@ -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" }
|
||||
|
|
|
@ -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,
|
||||
|
|
23
bfd/intobfd
23
bfd/intobfd
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -1,2 +1 @@
|
|||
/---------------START FROM/,/---------------END FROM/d
|
||||
/\/\* FROM coffcode.h\*\//r coffcode.p
|
||||
/\/\*:coffcode.h\*\//r coffcode.p
|
||||
|
|
Loading…
Reference in a new issue