summaryrefslogtreecommitdiffstats
path: root/contrib/binutils/bfd/doc/bfdio.texi
diff options
context:
space:
mode:
authordim <dim@FreeBSD.org>2010-11-01 19:35:33 +0000
committerdim <dim@FreeBSD.org>2010-11-01 19:35:33 +0000
commit3f5c947f4453c6016a2a6a9636367ee3f48fc6fc (patch)
tree461aafc934d462eb9b9221308f8e25238c0ada62 /contrib/binutils/bfd/doc/bfdio.texi
parente6be3e7867eb43d220575baee2ce5662fb03e46c (diff)
parentd0f678fa0ff3f08a4eca29daf4d1ac39797b6326 (diff)
downloadFreeBSD-src-3f5c947f4453c6016a2a6a9636367ee3f48fc6fc.zip
FreeBSD-src-3f5c947f4453c6016a2a6a9636367ee3f48fc6fc.tar.gz
Merge ^/vendor/binutils/dist@214571 into contrib/binutils, which brings
us up to version 2.17.50.20070703, at the last GPLv2 commit. Amongst others, this added upstream support for some FreeBSD-specific things that we previously had to manually hack in, such as the OSABI label support, and so on. There are also quite a number of new files, some for cpu's (e.g. SPU) that we may or may not be interested in, but those can be cleaned up later on, if needed.
Diffstat (limited to 'contrib/binutils/bfd/doc/bfdio.texi')
-rw-r--r--contrib/binutils/bfd/doc/bfdio.texi72
1 files changed, 0 insertions, 72 deletions
diff --git a/contrib/binutils/bfd/doc/bfdio.texi b/contrib/binutils/bfd/doc/bfdio.texi
deleted file mode 100644
index eb7e31d..0000000
--- a/contrib/binutils/bfd/doc/bfdio.texi
+++ /dev/null
@@ -1,72 +0,0 @@
-@findex struct bfd_iovec
-@subsubsection @code{struct bfd_iovec}
-@strong{Description}@*
-The @code{struct bfd_iovec} contains the internal file I/O class.
-Each @code{BFD} has an instance of this class and all file I/O is
-routed through it (it is assumed that the instance implements
-all methods listed below).
-@example
-struct bfd_iovec
-@{
- /* To avoid problems with macros, a "b" rather than "f"
- prefix is prepended to each method name. */
- /* Attempt to read/write NBYTES on ABFD's IOSTREAM storing/fetching
- bytes starting at PTR. Return the number of bytes actually
- transfered (a read past end-of-file returns less than NBYTES),
- or -1 (setting @code{bfd_error}) if an error occurs. */
- file_ptr (*bread) (struct bfd *abfd, void *ptr, file_ptr nbytes);
- file_ptr (*bwrite) (struct bfd *abfd, const void *ptr,
- file_ptr nbytes);
- /* Return the current IOSTREAM file offset, or -1 (setting @code{bfd_error}
- if an error occurs. */
- file_ptr (*btell) (struct bfd *abfd);
- /* For the following, on successful completion a value of 0 is returned.
- Otherwise, a value of -1 is returned (and @code{bfd_error} is set). */
- int (*bseek) (struct bfd *abfd, file_ptr offset, int whence);
- int (*bclose) (struct bfd *abfd);
- int (*bflush) (struct bfd *abfd);
- int (*bstat) (struct bfd *abfd, struct stat *sb);
-@};
-@end example
-
-@findex bfd_get_mtime
-@subsubsection @code{bfd_get_mtime}
-@strong{Synopsis}
-@example
-long bfd_get_mtime (bfd *abfd);
-@end example
-@strong{Description}@*
-Return the file modification time (as read from the file system, or
-from the archive header for archive members).
-
-@findex bfd_get_size
-@subsubsection @code{bfd_get_size}
-@strong{Synopsis}
-@example
-long bfd_get_size (bfd *abfd);
-@end example
-@strong{Description}@*
-Return the file size (as read from file system) for the file
-associated with BFD @var{abfd}.
-
-The initial motivation for, and use of, this routine is not
-so we can get the exact size of the object the BFD applies to, since
-that might not be generally possible (archive members for example).
-It would be ideal if someone could eventually modify
-it so that such results were guaranteed.
-
-Instead, we want to ask questions like "is this NNN byte sized
-object I'm about to try read from file offset YYY reasonable?"
-As as example of where we might do this, some object formats
-use string tables for which the first @code{sizeof (long)} bytes of the
-table contain the size of the table itself, including the size bytes.
-If an application tries to read what it thinks is one of these
-string tables, without some way to validate the size, and for
-some reason the size is wrong (byte swapping error, wrong location
-for the string table, etc.), the only clue is likely to be a read
-error when it tries to read the table, or a "virtual memory
-exhausted" error when it tries to allocate 15 bazillon bytes
-of space for the 15 bazillon byte table it is about to read.
-This function at least allows us to answer the question, "is the
-size reasonable?".
-
OpenPOWER on IntegriCloud