OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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:
Roland Pesch 1991-08-21 21:37:39 +00:00
parent 90125c8596
commit dd260c230b
8 changed files with 48 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bfd/ChangeLog
View 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)

6
bfd/Makefile.in
View 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:

8
bfd/awkscan-ip
View File

@ -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" }

8
bfd/awkscan-p
View File

@ -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" }

28
bfd/bfd.texinfo
View File

@ -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
View File

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

6
bfd/tolibbfd
View File

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

3
bfd/tolibcoff
View File

@ -1,2 +1 @@
/---------------START FROM/,/---------------END FROM/d
/\/\* FROM coffcode.h\*\//r coffcode.p
/\/\*:coffcode.h\*\//r coffcode.p