This is Info file binutils.info, produced by Makeinfo-1.64 from the input file ./binutils.texi. START-INFO-DIR-ENTRY * Binutils: (binutils). The GNU binary utilities "ar", "objcopy", "objdump", "nm", "nlmconv", "size", "strings", "strip", and "ranlib". END-INFO-DIR-ENTRY Copyright (C) 1991, 92, 93, 94, 95, 96, 1997 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.  File: binutils.info, Node: c++filt, Next: addr2line, Prev: strip, Up: Top c++filt ******* c++filt [ -_ | --strip-underscores ] [ -n | --no-strip-underscores ] [ -s FORMAT | --format=FORMAT ] [ --help ] [ --version ] [ SYMBOL... ] The C++ language provides function overloading, which means that you can write many functions with the same name (providing each takes parameters of different types). All C++ function names are encoded into a low-level assembly label (this process is known as "mangling"). The `c++filt' program does the inverse mapping: it decodes ("demangles") low-level names into user-level names so that the linker can keep these overloaded functions from clashing. Every alphanumeric word (consisting of letters, digits, underscores, dollars, or periods) seen in the input is a potential label. If the label decodes into a C++ name, the C++ name replaces the low-level name in the output. You can use `c++filt' to decipher individual symbols: c++filt SYMBOL If no SYMBOL arguments are given, `c++filt' reads symbol names from the standard input and writes the demangled names to the standard output. All results are printed on the standard output. `-_' `--strip-underscores' On some systems, both the C and C++ compilers put an underscore in front of every name. For example, the C name `foo' gets the low-level name `_foo'. This option removes the initial underscore. Whether `c++filt' removes the underscore by default is target dependent. `-n' `--no-strip-underscores' Do not remove the initial underscore. `-s FORMAT' `--format=FORMAT' GNU `nm' can decode three different methods of mangling, used by different C++ compilers. The argument to this option selects which method it uses: `gnu' the one used by the GNU compiler (the default method) `lucid' the one used by the Lucid compiler `arm' the one specified by the C++ Annotated Reference Manual `--help' Print a summary of the options to `c++filt' and exit. `--version' Print the version number of `c++filt' and exit. *Warning:* `c++filt' is a new utility, and the details of its user interface are subject to change in future releases. In particular, a command-line option may be required in the the future to decode a name passed as an argument on the command line; in other words, c++filt SYMBOL may in a future release become c++filt OPTION SYMBOL  File: binutils.info, Node: addr2line, Next: nlmconv, Prev: c++filt, Up: Top addr2line ********* addr2line [ -b BFDNAME | --target=BFDNAME ] [ -C | --demangle ] [ -e FILENAME | --exe=FILENAME ] [ -f | --functions ] [ -s | --basename ] [ -H | --help ] [ -V | --version ] [ addr addr ... ] `addr2line' translates program addresses into file names and line numbers. Given an address and an executable, it uses the debugging information in the executable to figure out which file name and line number are associated with a given address. The executable to use is specified with the `-e' option. The default is `a.out'. `addr2line' has two modes of operation. In the first, hexadecimal addresses are specified on the command line, and `addr2line' displays the file name and line number for each address. In the second, `addr2line' reads hexadecimal addresses from standard input, and prints the file name and line number for each address on standard output. In this mode, `addr2line' may be used in a pipe to convert dynamically chosen addresses. The format of the output is `FILENAME:LINENO'. The file name and line number for each address is printed on a separate line. If the `-f' option is used, then each `FILENAME:LINENO' line is preceded by a `FUNCTIONNAME' line which is the name of the function containing the address. If the file name or function name can not be determined, `addr2line' will print two question marks in their place. If the line number can not be determined, `addr2line' will print 0. The long and short forms of options, shown here as alternatives, are equivalent. `-b BFDNAME' `--target=BFDNAME' Specify that the object-code format for the object files is BFDNAME. `-C' `--demangle' Decode ("demangle") low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes C++ function names readable. *Note c++filt::, for more information on demangling. `-e FILENAME' `--exe=FILENAME' Specify the name of the executable for which addresses should be translated. The default file is `a.out'. `-f' `--functions' Display function names as well as file and line number information. `-s' `--basenames' Display only the base of each file name.  File: binutils.info, Node: nlmconv, Next: Selecting The Target System, Prev: addr2line, Up: Top nlmconv ******* `nlmconv' converts a relocatable object file into a NetWare Loadable Module. *Warning:* `nlmconv' is not always built as part of the binary utilities, since it is only useful for NLM targets. nlmconv [ -I BFDNAME | --input-target=BFDNAME ] [ -O BFDNAME | --output-target=BFDNAME ] [ -T HEADERFILE | --header-file=HEADERFILE ] [ -d | --debug] [ -l LINKER | --linker=LINKER ] [ -h | --help ] [ -V | --version ] INFILE OUTFILE `nlmconv' converts the relocatable `i386' object file INFILE into the NetWare Loadable Module OUTFILE, optionally reading HEADERFILE for NLM header information. For instructions on writing the NLM command file language used in header files, see the `linkers' section, `NLMLINK' in particular, of the `NLM Development and Tools Overview', which is part of the NLM Software Developer's Kit ("NLM SDK"), available from Novell, Inc. `nlmconv' uses the GNU Binary File Descriptor library to read INFILE; see *Note BFD: (ld.info)BFD, for more information. `nlmconv' can perform a link step. In other words, you can list more than one object file for input if you list them in the definitions file (rather than simply specifying one input file on the command line). In this case, `nlmconv' calls the linker for you. `-I BFDNAME' `--input-target=BFDNAME' Object format of the input file. `nlmconv' can usually determine the format of a given file (so no default is necessary). *Note Target Selection::, for more information. `-O BFDNAME' `--output-target=BFDNAME' Object format of the output file. `nlmconv' infers the output format based on the input format, e.g. for a `i386' input file the output format is `nlm32-i386'. *Note Target Selection::, for more information. `-T HEADERFILE' `--header-file=HEADERFILE' Reads HEADERFILE for NLM header information. For instructions on writing the NLM command file language used in header files, see see the `linkers' section, of the `NLM Development and Tools Overview', which is part of the NLM Software Developer's Kit, available from Novell, Inc. `-d' `--debug' Displays (on standard error) the linker command line used by `nlmconv'. `-l LINKER' `--linker=LINKER' Use LINKER for any linking. LINKER can be an abosolute or a relative pathname. `-h' `--help' Prints a usage summary. `-V' `--version' Prints the version number for `nlmconv'.  File: binutils.info, Node: Selecting The Target System, Next: Reporting Bugs, Prev: nlmconv, Up: Top Selecting the target system *************************** You can specify three aspects of the target system to the GNU binary file utilities, each in several ways: * the target * the architecture * the linker emulation (which applies to the linker only) In the following summaries, the lists of ways to specify values are in order of decreasing precedence. The ways listed first override those listed later. The commands to list valid values only list the values for which the programs you are running were configured. If they were configured with `--enable-targets=all', the commands list most of the available values, but a few are left out; not all targets can be configured in at once because some of them can only be configured "native" (on hosts with the same type as the target system). * Menu: * Target Selection:: * Architecture Selection:: * Linker Emulation Selection::  File: binutils.info, Node: Target Selection, Next: Architecture Selection, Up: Selecting The Target System Target Selection ================ A "target" is an object file format. A given target may be supported for multiple architectures (*note Architecture Selection::.). A target selection may also have variations for different operating systems or architectures. The command to list valid target values is `objdump -i' (the first column of output contains the relevant information). Some sample values are: `a.out-hp300bsd', `ecoff-littlemips', `a.out-sunos-big'. You can also specify a target using a configuration triplet. This is the same sort of name that is passed to configure to specify a target. When you use a configuration triplet as an argument, it must be fully canonicalized. You can see the canonical version of a triplet by running the shell script `config.sub' which is included with the sources. Some sample configuration triplets are: `m68k-hp-bsd', `mips-dec-ultrix', `sparc-sun-sunos'. `objdump' Target ---------------- Ways to specify: 1. command line option: `-b' or `--target' 2. environment variable `GNUTARGET' 3. deduced from the input file `objcopy' and `strip' Input Target ---------------------------------- Ways to specify: 1. command line options: `-I' or `--input-target', or `-F' or `--target' 2. environment variable `GNUTARGET' 3. deduced from the input file `objcopy' and `strip' Output Target ----------------------------------- Ways to specify: 1. command line options: `-O' or `--output-target', or `-F' or `--target' 2. the input target (see "`objcopy' and `strip' Input Target" above) 3. environment variable `GNUTARGET' 4. deduced from the input file `nm', `size', and `strings' Target ---------------------------------- Ways to specify: 1. command line option: `--target' 2. environment variable `GNUTARGET' 3. deduced from the input file Linker Input Target ------------------- Ways to specify: 1. command line option: `-b' or `--format' (*note Options: (ld.info)Options.) 2. script command `TARGET' (*note Option Commands: (ld.info)Option Commands.) 3. environment variable `GNUTARGET' (*note Environment: (ld.info)Environment.) 4. the default target of the selected linker emulation (*note Linker Emulation Selection::.) Linker Output Target -------------------- Ways to specify: 1. command line option: `-oformat' (*note Options: (ld.info)Options.) 2. script command `OUTPUT_FORMAT' (*note Option Commands: (ld.info)Option Commands.) 3. the linker input target (see "Linker Input Target" above)  File: binutils.info, Node: Architecture Selection, Next: Linker Emulation Selection, Prev: Target Selection, Up: Selecting The Target System Architecture selection ====================== An "architecture" is a type of CPU on which an object file is to run. Its name may contain a colon, separating the name of the processor family from the name of the particular CPU. The command to list valid architecture values is `objdump -i' (the second column contains the relevant information). Sample values: `m68k:68020', `mips:3000', `sparc'. `objdump' Architecture ---------------------- Ways to specify: 1. command line option: `-m' or `--architecture' 2. deduced from the input file `objcopy', `nm', `size', `strings' Architecture ----------------------------------------------- Ways to specify: 1. deduced from the input file Linker Input Architecture ------------------------- Ways to specify: 1. deduced from the input file Linker Output Architecture -------------------------- Ways to specify: 1. script command `OUTPUT_ARCH' (*note Option Commands: (ld.info)Option Commands.) 2. the default architecture from the linker output target (*note Target Selection::.)  File: binutils.info, Node: Linker Emulation Selection, Prev: Architecture Selection, Up: Selecting The Target System Linker emulation selection ========================== A linker "emulation" is a "personality" of the linker, which gives the linker default values for the other aspects of the target system. In particular, it consists of * the linker script * the target * several "hook" functions that are run at certain stages of the linking process to do special things that some targets require The command to list valid linker emulation values is `ld -V'. Sample values: `hp300bsd', `mipslit', `sun4'. Ways to specify: 1. command line option: `-m' (*note Options: (ld.info)Options.) 2. environment variable `LDEMULATION' 3. compiled-in `DEFAULT_EMULATION' from `Makefile', which comes from `EMUL' in `config/TARGET.mt'  File: binutils.info, Node: Reporting Bugs, Next: Index, Prev: Selecting The Target System, Up: Top Reporting Bugs ************** Your bug reports play an essential role in making the binary utilities reliable. Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of the binary utilities work better. Bug reports are your contribution to their maintenance. In order for a bug report to serve its purpose, you must include the information that enables us to fix the bug. * Menu: * Bug Criteria:: Have you found a bug? * Bug Reporting:: How to report bugs  File: binutils.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs Have you found a bug? ===================== If you are not sure whether you have found a bug, here are some guidelines: * If a binary utility gets a fatal signal, for any input whatever, that is a bug. Reliable utilities never crash. * If a binary utility produces an error message for valid input, that is a bug. * If you are an experienced user of binary utilities, your suggestions for improvement are welcome in any case.  File: binutils.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs How to report bugs ================== A number of companies and individuals offer support for GNU products. If you obtained the binary utilities from a support organization, we recommend you contact that organization first. You can find contact information for many support companies and individuals in the file `etc/SERVICE' in the GNU Emacs distribution. In any event, we also recommend that you send bug reports for the binary utilities to `bug-gnu-utils@prep.ai.mit.edu'. The fundamental principle of reporting bugs usefully is this: *report all the facts*. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of a file you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that pathname is stored in memory; perhaps, if the pathname were different, the contents of that location would fool the utility into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful. Keep in mind that the purpose of a bug report is to enable us to fix the bug if it is new to us. Therefore, always write your bug reports on the assumption that the bug has not been reported previously. Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" Those bug reports are useless, and we urge everyone to *refuse to respond to them* except to chide the sender to report bugs properly. To enable us to fix the bug, you should include all these things: * The version of the utility. Each utility announces it if you start it with the `--version' argument. Without this, we will not know whether there is any point in looking for the bug in the current version of the binary utilities. * Any patches you may have applied to the source, including any patches made to the `BFD' library. * The type of machine you are using, and the operating system name and version number. * What compiler (and its version) was used to compile the utilities--e.g. "`gcc-2.7'". * The command arguments you gave the utility to observe the bug. To guarantee you will not omit something important, list them all. A copy of the Makefile (or the output from make) is sufficient. If we were to try to guess the arguments, we would probably guess wrong and then we might not encounter the bug. * A complete input file, or set of input files, that will reproduce the bug. If the utility is reading an object file or files, then it is generally most helpful to send the actual object files, uuencoded if necessary to get them through the mail system. Making them available for anonymous FTP is not as good, but may be the only reasonable choice for large object files. If the source files were produced exclusively using GNU programs (e.g., `gcc', `gas', and/or the GNU `ld'), then it may be OK to send the source files rather than the object files. In this case, be sure to say exactly what version of `gcc', or whatever, was used to produce the object files. Also say how `gcc', or whatever, was configured. * A description of what behavior you observe that you believe is incorrect. For example, "It gets a fatal signal." Of course, if the bug is that the utility gets a fatal signal, then we will certainly notice it. But if the bug is incorrect output, we might not notice unless it is glaringly wrong. You might as well not give us a chance to make a mistake. Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of the utility is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and ours would not. If you told us to expect a crash, then when ours fails to crash, we would know that the bug was not happening for us. If you had not told us to expect a crash, then we would not be able to draw any conclusion from our observations. * If you wish to suggest changes to the source, send us context diffs, as generated by `diff' with the `-u', `-c', or `-p' option. Always send diffs from the old file to the new file. If you even discuss something in the `ld' source, refer to it by context, not by line number. The line numbers in our development sources will not match those in your sources. Your line numbers would convey no useful information to us. Here are some things that are not necessary: * A description of the envelope of the bug. Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. We recommend that you save your time for something else. Of course, if you can find a simpler example to report *instead* of the original one, that is a convenience for us. Errors in the output will be easier to spot, running under the debugger will take less time, and so on. However, simplification is not vital; if you do not want to do this, report the bug anyway and send us the entire test case you used. * A patch for the bug. A patch for the bug does help us if it is a good one. But do not omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all. Sometimes with programs as complicated as the binary utilities it is very hard to construct an example that will make the program follow a certain path through the code. If you do not send us the example, we will not be able to construct one, so we will not be able to verify that the bug is fixed. And if we cannot understand what bug you are trying to fix, or why your patch should be an improvement, we will not install it. A test case will help us to understand. * A guess about what the bug is or what it depends on. Such guesses are usually wrong. Even we cannot guess right about such things without first using the debugger to find the facts.  File: binutils.info, Node: Index, Prev: Reporting Bugs, Up: Top Index ***** * Menu: * .stab: objdump. * ar compatibility: ar. * nm compatibility: nm. * nm format: nm. * size display format: size. * size number format: size. * addr2line: addr2line. * address to file name and line number: addr2line. * all header information, object file: objdump. * ar: ar. * architecture: objdump. * architectures available: objdump. * archive contents: ranlib. * archive headers: objdump. * archives: ar. * bug criteria: Bug Criteria. * bug reports: Bug Reporting. * bugs: Reporting Bugs. * bugs, reporting: Bug Reporting. * c++filt: c++filt. * collections of files: ar. * compatibility, ar: ar. * contents of archive: ar cmdline. * crash: Bug Criteria. * creating archives: ar cmdline. * dates in archive: ar cmdline. * debug symbols: objdump. * debugging symbols: nm. * deleting from archive: ar cmdline. * demangling C++ symbols: c++filt. * demangling in nm: nm. * demangling in objdump <1>: objdump. * demangling in objdump: addr2line. * disassembling object code: objdump. * disassembly architecture: objdump. * disassembly endianness: objdump. * disassembly, with source: objdump. * discarding symbols: strip. * dynamic relocation entries, in object file: objdump. * dynamic symbol table entries, printing: objdump. * dynamic symbols: nm. * ELF object file format: objdump. * endianness: objdump. * error on valid input: Bug Criteria. * external symbols: nm. * extract from archive: ar cmdline. * fatal signal: Bug Criteria. * file name: nm. * header information, all: objdump. * input file name: nm. * libraries: ar. * listings strings: strings. * machine instructions: objdump. * moving in archive: ar cmdline. * MRI compatibility, ar: ar scripts. * name duplication in archive: ar cmdline. * name length: ar. * nm: nm. * objdump: objdump. * object code format <1>: objdump. * object code format <2>: strings. * object code format <3>: nm. * object code format <4>: size. * object code format: addr2line. * object file header: objdump. * object file information: objdump. * object file sections: objdump. * object formats available: objdump. * operations on archive: ar cmdline. * printing from archive: ar cmdline. * printing strings: strings. * quick append to archive: ar cmdline. * radix for section sizes: size. * ranlib: ranlib. * relative placement in archive: ar cmdline. * relocation entries, in object file: objdump. * removing symbols: strip. * repeated names in archive: ar cmdline. * replacement in archive: ar cmdline. * reporting bugs: Reporting Bugs. * scripts, ar: ar scripts. * section addresses in objdump: objdump. * section headers: objdump. * section information: objdump. * section sizes: size. * sections, full contents: objdump. * size: size. * sorting symbols: nm. * source disassembly: objdump. * source file name: nm. * source filenames for object files: objdump. * stab: objdump. * start-address: objdump. * stop-address: objdump. * strings: strings. * strings, printing: strings. * strip: strip. * symbol index <1>: ranlib. * symbol index: ar. * symbol index, listing: nm. * symbol line numbers: nm. * symbol table entries, printing: objdump. * symbols: nm. * symbols, discarding: strip. * undefined symbols: nm. * Unix compatibility, ar: ar cmdline. * updating an archive: ar cmdline. * version: Top. * VMA in objdump: objdump. * wide output, printing: objdump. * writing archive index: ar cmdline.