head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC6:1.1.1.9 netbsd-11-0-RC5:1.1.1.9 netbsd-11-0-RC4:1.1.1.9 netbsd-11-0-RC3:1.1.1.9 gdb-17-1:1.1.1.10 netbsd-11-0-RC2:1.1.1.9 netbsd-11-0-RC1:1.1.1.9 gdb-16-3:1.1.1.9 perseant-exfatfs-base-20250801:1.1.1.9 netbsd-11:1.1.1.9.0.2 netbsd-11-base:1.1.1.9 netbsd-10-1-RELEASE:1.1.1.7 gdb-15-1:1.1.1.9 perseant-exfatfs-base-20240630:1.1.1.8 perseant-exfatfs:1.1.1.8.0.2 perseant-exfatfs-base:1.1.1.8 netbsd-8-3-RELEASE:1.1.1.4 netbsd-9-4-RELEASE:1.1.1.6 netbsd-10-0-RELEASE:1.1.1.7 netbsd-10-0-RC6:1.1.1.7 netbsd-10-0-RC5:1.1.1.7 netbsd-10-0-RC4:1.1.1.7 netbsd-10-0-RC3:1.1.1.7 netbsd-10-0-RC2:1.1.1.7 netbsd-10-0-RC1:1.1.1.7 gdb-13-2:1.1.1.8 netbsd-10:1.1.1.7.0.6 netbsd-10-base:1.1.1.7 netbsd-9-3-RELEASE:1.1.1.6 cjep_sun2x-base1:1.1.1.7 cjep_sun2x:1.1.1.7.0.4 cjep_sun2x-base:1.1.1.7 cjep_staticlib_x-base1:1.1.1.7 netbsd-9-2-RELEASE:1.1.1.6 cjep_staticlib_x:1.1.1.7.0.2 cjep_staticlib_x-base:1.1.1.7 netbsd-9-1-RELEASE:1.1.1.6 GDB-11-0-50-20200914-git:1.1.1.7 phil-wifi-20200421:1.1.1.6 phil-wifi-20200411:1.1.1.6 is-mlppp:1.1.1.6.0.4 is-mlppp-base:1.1.1.6 phil-wifi-20200406:1.1.1.6 netbsd-8-2-RELEASE:1.1.1.4 netbsd-9-0-RELEASE:1.1.1.6 netbsd-9-0-RC2:1.1.1.6 netbsd-9-0-RC1:1.1.1.6 phil-wifi-20191119:1.1.1.6 netbsd-9:1.1.1.6.0.2 netbsd-9-base:1.1.1.6 phil-wifi-20190609:1.1.1.6 netbsd-8-1-RELEASE:1.1.1.4 gdb-8-3:1.1.1.6 netbsd-8-1-RC1:1.1.1.4 pgoyette-compat-merge-20190127:1.1.1.5 pgoyette-compat-20190127:1.1.1.5 pgoyette-compat-20190118:1.1.1.5 pgoyette-compat-1226:1.1.1.5 pgoyette-compat-1126:1.1.1.5 pgoyette-compat-1020:1.1.1.5 pgoyette-compat-0930:1.1.1.5 pgoyette-compat-0906:1.1.1.5 netbsd-7-2-RELEASE:1.1.1.2 pgoyette-compat-0728:1.1.1.5 netbsd-8-0-RELEASE:1.1.1.4 phil-wifi:1.1.1.5.0.4 phil-wifi-base:1.1.1.5 pgoyette-compat-0625:1.1.1.5 netbsd-8-0-RC2:1.1.1.4 pgoyette-compat-0521:1.1.1.5 pgoyette-compat-0502:1.1.1.5 pgoyette-compat-0422:1.1.1.5 netbsd-8-0-RC1:1.1.1.4 pgoyette-compat-0415:1.1.1.5 pgoyette-compat-0407:1.1.1.5 pgoyette-compat-0330:1.1.1.5 pgoyette-compat-0322:1.1.1.5 pgoyette-compat-0315:1.1.1.5 netbsd-7-1-2-RELEASE:1.1.1.2 pgoyette-compat:1.1.1.5.0.2 pgoyette-compat-base:1.1.1.5 netbsd-7-1-1-RELEASE:1.1.1.2 gdb-8-0-1:1.1.1.5 matt-nb8-mediatek:1.1.1.4.0.10 matt-nb8-mediatek-base:1.1.1.4 perseant-stdc-iso10646:1.1.1.4.0.8 perseant-stdc-iso10646-base:1.1.1.4 netbsd-8:1.1.1.4.0.6 netbsd-8-base:1.1.1.4 prg-localcount2-base3:1.1.1.4 prg-localcount2-base2:1.1.1.4 prg-localcount2-base1:1.1.1.4 prg-localcount2:1.1.1.4.0.4 prg-localcount2-base:1.1.1.4 pgoyette-localcount-20170426:1.1.1.4 bouyer-socketcan-base1:1.1.1.4 pgoyette-localcount-20170320:1.1.1.4 netbsd-7-1:1.1.1.2.0.8 netbsd-7-1-RELEASE:1.1.1.2 netbsd-7-1-RC2:1.1.1.2 netbsd-7-nhusb-base-20170116:1.1.1.2 bouyer-socketcan:1.1.1.4.0.2 bouyer-socketcan-base:1.1.1.4 pgoyette-localcount-20170107:1.1.1.4 netbsd-7-1-RC1:1.1.1.2 pgoyette-localcount-20161104:1.1.1.4 netbsd-7-0-2-RELEASE:1.1.1.2 gdb-7-12:1.1.1.4 localcount-20160914:1.1.1.3 netbsd-7-nhusb:1.1.1.2.0.6 netbsd-7-nhusb-base:1.1.1.2 pgoyette-localcount-20160806:1.1.1.3 pgoyette-localcount-20160726:1.1.1.3 pgoyette-localcount:1.1.1.3.0.2 pgoyette-localcount-base:1.1.1.3 netbsd-7-0-1-RELEASE:1.1.1.2 gdb-7-10-1:1.1.1.3 netbsd-7-0:1.1.1.2.0.4 netbsd-7-0-RELEASE:1.1.1.2 gdb-7-9-1:1.1.1.3 netbsd-7-0-RC3:1.1.1.2 netbsd-7-0-RC2:1.1.1.2 netbsd-7-0-RC1:1.1.1.2 netbsd-6-0-6-RELEASE:1.1.1.1 netbsd-6-1-5-RELEASE:1.1.1.1 netbsd-7:1.1.1.2.0.2 netbsd-7-base:1.1.1.2 gdb-7-7-1:1.1.1.2 yamt-pagecache-base9:1.1.1.1 yamt-pagecache-tag8:1.1.1.1 netbsd-6-1-4-RELEASE:1.1.1.1 netbsd-6-0-5-RELEASE:1.1.1.1 tls-earlyentropy:1.1.1.1.0.18 tls-earlyentropy-base:1.1.1.2 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.1 riastradh-drm2-base3:1.1.1.1 netbsd-6-1-3-RELEASE:1.1.1.1 netbsd-6-0-4-RELEASE:1.1.1.1 gdb-7-6-1:1.1.1.1 netbsd-6-1-2-RELEASE:1.1.1.1 netbsd-6-0-3-RELEASE:1.1.1.1 netbsd-6-1-1-RELEASE:1.1.1.1 riastradh-drm2-base2:1.1.1.1 riastradh-drm2-base1:1.1.1.1 riastradh-drm2:1.1.1.1.0.12 riastradh-drm2-base:1.1.1.1 netbsd-6-1:1.1.1.1.0.16 netbsd-6-0-2-RELEASE:1.1.1.1 netbsd-6-1-RELEASE:1.1.1.1 netbsd-6-1-RC4:1.1.1.1 netbsd-6-1-RC3:1.1.1.1 agc-symver:1.1.1.1.0.14 agc-symver-base:1.1.1.1 netbsd-6-1-RC2:1.1.1.1 netbsd-6-1-RC1:1.1.1.1 yamt-pagecache-base8:1.1.1.1 netbsd-6-0-1-RELEASE:1.1.1.1 yamt-pagecache-base7:1.1.1.1 matt-nb6-plus-nbase:1.1.1.1 yamt-pagecache-base6:1.1.1.1 netbsd-6-0:1.1.1.1.0.10 netbsd-6-0-RELEASE:1.1.1.1 netbsd-6-0-RC2:1.1.1.1 tls-maxphys:1.1.1.1.0.8 tls-maxphys-base:1.1.1.2 matt-nb6-plus:1.1.1.1.0.6 matt-nb6-plus-base:1.1.1.1 netbsd-6-0-RC1:1.1.1.1 yamt-pagecache-base5:1.1.1.1 yamt-pagecache-base4:1.1.1.1 netbsd-6:1.1.1.1.0.4 netbsd-6-base:1.1.1.1 yamt-pagecache-base3:1.1.1.1 yamt-pagecache-base2:1.1.1.1 yamt-pagecache:1.1.1.1.0.2 yamt-pagecache-base:1.1.1.1 gdb-7-3-1:1.1.1.1 FSF:1.1.1; locks; strict; comment @# @; 1.1 date 2011.09.24.19.47.35; author christos; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2011.09.24.19.47.35; author christos; state Exp; branches 1.1.1.1.8.1 1.1.1.1.18.1; next 1.1.1.2; 1.1.1.2 date 2014.06.22.23.40.06; author christos; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2015.08.15.10.05.50; author christos; state Exp; branches 1.1.1.3.2.1; next 1.1.1.4; commitid HQEGxxDWfd9mFlxy; 1.1.1.4 date 2016.10.12.16.48.43; author christos; state Exp; branches; next 1.1.1.5; commitid WncVqozyBBQMmSpz; 1.1.1.5 date 2017.11.28.18.19.06; author christos; state Exp; branches 1.1.1.5.4.1; next 1.1.1.6; commitid rE0LxHFEMFCrCPgA; 1.1.1.6 date 2019.05.26.21.00.30; author christos; state Exp; branches; next 1.1.1.7; commitid MDatjuvRsk0MXKoB; 1.1.1.7 date 2020.09.15.01.42.04; author christos; state Exp; branches; next 1.1.1.8; commitid N511ReXja24bg5oC; 1.1.1.8 date 2023.07.30.22.45.53; author christos; state Exp; branches 1.1.1.8.2.1; next 1.1.1.9; commitid HEIv4Prd74m1wSyE; 1.1.1.9 date 2024.08.12.21.39.06; author christos; state Exp; branches; next 1.1.1.10; commitid dWD83H91pFit0AlF; 1.1.1.10 date 2026.03.14.20.44.45; author christos; state Exp; branches; next ; commitid FYd84EijbJAv3ZxG; 1.1.1.1.8.1 date 2014.08.19.23.58.38; author tls; state Exp; branches; next ; commitid jTnpym9Qu0o4R1Nx; 1.1.1.1.18.1 date 2014.08.10.07.11.38; author tls; state Exp; branches; next ; commitid I2ai4RKW1zrCHMLx; 1.1.1.3.2.1 date 2016.11.04.14.46.48; author pgoyette; state Exp; branches; next ; commitid 2m1JRwYmpwPkOOsz; 1.1.1.5.4.1 date 2019.06.10.21.58.29; author christos; state Exp; branches; next ; commitid jtc8rnCzWiEEHGqB; 1.1.1.8.2.1 date 2025.08.02.05.26.35; author perseant; state Exp; branches; next ; commitid 23j6GFaDws3O875G; desc @@ 1.1 log @Initial revision @ text @\input texinfo @@c Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, @@c 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2009 @@c Free Software Foundation, Inc. @@setfilename bfdint.info @@settitle BFD Internals @@iftex @@titlepage @@title{BFD Internals} @@author{Ian Lance Taylor} @@author{Cygnus Solutions} @@page @@end iftex @@copying This file documents the internals of the BFD library. Copyright @@copyright{} 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2009 Free Software Foundation, Inc. Contributed by Cygnus Support. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. @@end copying @@node Top @@top BFD Internals @@raisesections @@cindex bfd internals This document describes some BFD internal information which may be helpful when working on BFD. It is very incomplete. This document is not updated regularly, and may be out of date. The initial version of this document was written by Ian Lance Taylor @@email{ian@@@@cygnus.com}. @@menu * BFD overview:: BFD overview * BFD guidelines:: BFD programming guidelines * BFD target vector:: BFD target vector * BFD generated files:: BFD generated files * BFD multiple compilations:: Files compiled multiple times in BFD * BFD relocation handling:: BFD relocation handling * BFD ELF support:: BFD ELF support * BFD glossary:: Glossary * Index:: Index @@end menu @@node BFD overview @@section BFD overview BFD is a library which provides a single interface to read and write object files, executables, archive files, and core files in any format. @@menu * BFD library interfaces:: BFD library interfaces * BFD library users:: BFD library users * BFD view:: The BFD view of a file * BFD blindness:: BFD loses information @@end menu @@node BFD library interfaces @@subsection BFD library interfaces One way to look at the BFD library is to divide it into four parts by type of interface. The first interface is the set of generic functions which programs using the BFD library will call. These generic function normally translate directly or indirectly into calls to routines which are specific to a particular object file format. Many of these generic functions are actually defined as macros in @@file{bfd.h}. These functions comprise the official BFD interface. The second interface is the set of functions which appear in the target vectors. This is the bulk of the code in BFD. A target vector is a set of function pointers specific to a particular object file format. The target vector is used to implement the generic BFD functions. These functions are always called through the target vector, and are never called directly. The target vector is described in detail in @@ref{BFD target vector}. The set of functions which appear in a particular target vector is often referred to as a BFD backend. The third interface is a set of oddball functions which are typically specific to a particular object file format, are not generic functions, and are called from outside of the BFD library. These are used as hooks by the linker and the assembler when a particular object file format requires some action which the BFD generic interface does not provide. These functions are typically declared in @@file{bfd.h}, but in many cases they are only provided when BFD is configured with support for a particular object file format. These functions live in a grey area, and are not really part of the official BFD interface. The fourth interface is the set of BFD support functions which are called by the other BFD functions. These manage issues like memory allocation, error handling, file access, hash tables, swapping, and the like. These functions are never called from outside of the BFD library. @@node BFD library users @@subsection BFD library users Another way to look at the BFD library is to divide it into three parts by the manner in which it is used. The first use is to read an object file. The object file readers are programs like @@samp{gdb}, @@samp{nm}, @@samp{objdump}, and @@samp{objcopy}. These programs use BFD to view an object file in a generic form. The official BFD interface is normally fully adequate for these programs. The second use is to write an object file. The object file writers are programs like @@samp{gas} and @@samp{objcopy}. These programs use BFD to create an object file. The official BFD interface is normally adequate for these programs, but for some object file formats the assembler needs some additional hooks in order to set particular flags or other information. The official BFD interface includes functions to copy private information from one object file to another, and these functions are used by @@samp{objcopy} to avoid information loss. The third use is to link object files. There is only one object file linker, @@samp{ld}. Originally, @@samp{ld} was an object file reader and an object file writer, and it did the link operation using the generic BFD structures. However, this turned out to be too slow and too memory intensive. The official BFD linker functions were written to permit specific BFD backends to perform the link without translating through the generic structures, in the normal case where all the input files and output file have the same object file format. Not all of the backends currently implement the new interface, and there are default linking functions within BFD which use the generic structures and which work with all backends. For several object file formats the linker needs additional hooks which are not provided by the official BFD interface, particularly for dynamic linking support. These functions are typically called from the linker emulation template. @@node BFD view @@subsection The BFD view of a file BFD uses generic structures to manage information. It translates data into the generic form when reading files, and out of the generic form when writing files. BFD describes a file as a pointer to the @@samp{bfd} type. A @@samp{bfd} is composed of the following elements. The BFD information can be displayed using the @@samp{objdump} program with various options. @@table @@asis @@item general information The object file format, a few general flags, the start address. @@item architecture The architecture, including both a general processor type (m68k, MIPS etc.) and a specific machine number (m68000, R4000, etc.). @@item sections A list of sections. @@item symbols A symbol table. @@end table BFD represents a section as a pointer to the @@samp{asection} type. Each section has a name and a size. Most sections also have an associated block of data, known as the section contents. Sections also have associated flags, a virtual memory address, a load memory address, a required alignment, a list of relocations, and other miscellaneous information. BFD represents a relocation as a pointer to the @@samp{arelent} type. A relocation describes an action which the linker must take to modify the section contents. Relocations have a symbol, an address, an addend, and a pointer to a howto structure which describes how to perform the relocation. For more information, see @@ref{BFD relocation handling}. BFD represents a symbol as a pointer to the @@samp{asymbol} type. A symbol has a name, a pointer to a section, an offset within that section, and some flags. Archive files do not have any sections or symbols. Instead, BFD represents an archive file as a file which contains a list of @@samp{bfd}s. BFD also provides access to the archive symbol map, as a list of symbol names. BFD provides a function to return the @@samp{bfd} within the archive which corresponds to a particular entry in the archive symbol map. @@node BFD blindness @@subsection BFD loses information Most object file formats have information which BFD can not represent in its generic form, at least as currently defined. There is often explicit information which BFD can not represent. For example, the COFF version stamp, or the ELF program segments. BFD provides special hooks to handle this information when copying, printing, or linking an object file. The BFD support for a particular object file format will normally store this information in private data and handle it using the special hooks. In some cases there is also implicit information which BFD can not represent. For example, the MIPS processor distinguishes small and large symbols, and requires that all small symbols be within 32K of the GP register. This means that the MIPS assembler must be able to mark variables as either small or large, and the MIPS linker must know to put small symbols within range of the GP register. Since BFD can not represent this information, this means that the assembler and linker must have information that is specific to a particular object file format which is outside of the BFD library. This loss of information indicates areas where the BFD paradigm breaks down. It is not actually possible to represent the myriad differences among object file formats using a single generic interface, at least not in the manner which BFD does it today. Nevertheless, the BFD library does greatly simplify the task of dealing with object files, and particular problems caused by information loss can normally be solved using some sort of relatively constrained hook into the library. @@node BFD guidelines @@section BFD programming guidelines @@cindex bfd programming guidelines @@cindex programming guidelines for bfd @@cindex guidelines, bfd programming There is a lot of poorly written and confusing code in BFD. New BFD code should be written to a higher standard. Merely because some BFD code is written in a particular manner does not mean that you should emulate it. Here are some general BFD programming guidelines: @@itemize @@bullet @@item Follow the GNU coding standards. @@item Avoid global variables. We ideally want BFD to be fully reentrant, so that it can be used in multiple threads. All uses of global or static variables interfere with that. Initialized constant variables are OK, and they should be explicitly marked with @@samp{const}. Instead of global variables, use data attached to a BFD or to a linker hash table. @@item All externally visible functions should have names which start with @@samp{bfd_}. All such functions should be declared in some header file, typically @@file{bfd.h}. See, for example, the various declarations near the end of @@file{bfd-in.h}, which mostly declare functions required by specific linker emulations. @@item All functions which need to be visible from one file to another within BFD, but should not be visible outside of BFD, should start with @@samp{_bfd_}. Although external names beginning with @@samp{_} are prohibited by the ANSI standard, in practice this usage will always work, and it is required by the GNU coding standards. @@item Always remember that people can compile using @@samp{--enable-targets} to build several, or all, targets at once. It must be possible to link together the files for all targets. @@item BFD code should compile with few or no warnings using @@samp{gcc -Wall}. Some warnings are OK, like the absence of certain function declarations which may or may not be declared in system header files. Warnings about ambiguous expressions and the like should always be fixed. @@end itemize @@node BFD target vector @@section BFD target vector @@cindex bfd target vector @@cindex target vector in bfd BFD supports multiple object file formats by using the @@dfn{target vector}. This is simply a set of function pointers which implement behaviour that is specific to a particular object file format. In this section I list all of the entries in the target vector and describe what they do. @@menu * BFD target vector miscellaneous:: Miscellaneous constants * BFD target vector swap:: Swapping functions * BFD target vector format:: Format type dependent functions * BFD_JUMP_TABLE macros:: BFD_JUMP_TABLE macros * BFD target vector generic:: Generic functions * BFD target vector copy:: Copy functions * BFD target vector core:: Core file support functions * BFD target vector archive:: Archive functions * BFD target vector symbols:: Symbol table functions * BFD target vector relocs:: Relocation support * BFD target vector write:: Output functions * BFD target vector link:: Linker functions * BFD target vector dynamic:: Dynamic linking information functions @@end menu @@node BFD target vector miscellaneous @@subsection Miscellaneous constants The target vector starts with a set of constants. @@table @@samp @@item name The name of the target vector. This is an arbitrary string. This is how the target vector is named in command line options for tools which use BFD, such as the @@samp{--oformat} linker option. @@item flavour A general description of the type of target. The following flavours are currently defined: @@table @@samp @@item bfd_target_unknown_flavour Undefined or unknown. @@item bfd_target_aout_flavour a.out. @@item bfd_target_coff_flavour COFF. @@item bfd_target_ecoff_flavour ECOFF. @@item bfd_target_elf_flavour ELF. @@item bfd_target_ieee_flavour IEEE-695. @@item bfd_target_nlm_flavour NLM. @@item bfd_target_oasys_flavour OASYS. @@item bfd_target_tekhex_flavour Tektronix hex format. @@item bfd_target_srec_flavour Motorola S-record format. @@item bfd_target_ihex_flavour Intel hex format. @@item bfd_target_som_flavour SOM (used on HP/UX). @@item bfd_target_verilog_flavour Verilog memory hex dump format. @@item bfd_target_os9k_flavour os9000. @@item bfd_target_versados_flavour VERSAdos. @@item bfd_target_msdos_flavour MS-DOS. @@item bfd_target_evax_flavour openVMS. @@item bfd_target_mmo_flavour Donald Knuth's MMIXware object format. @@end table @@item byteorder The byte order of data in the object file. One of @@samp{BFD_ENDIAN_BIG}, @@samp{BFD_ENDIAN_LITTLE}, or @@samp{BFD_ENDIAN_UNKNOWN}. The latter would be used for a format such as S-records which do not record the architecture of the data. @@item header_byteorder The byte order of header information in the object file. Normally the same as the @@samp{byteorder} field, but there are certain cases where it may be different. @@item object_flags Flags which may appear in the @@samp{flags} field of a BFD with this format. @@item section_flags Flags which may appear in the @@samp{flags} field of a section within a BFD with this format. @@item symbol_leading_char A character which the C compiler normally puts before a symbol. For example, an a.out compiler will typically generate the symbol @@samp{_foo} for a function named @@samp{foo} in the C source, in which case this field would be @@samp{_}. If there is no such character, this field will be @@samp{0}. @@item ar_pad_char The padding character to use at the end of an archive name. Normally @@samp{/}. @@item ar_max_namelen The maximum length of a short name in an archive. Normally @@samp{14}. @@item backend_data A pointer to constant backend data. This is used by backends to store whatever additional information they need to distinguish similar target vectors which use the same sets of functions. @@end table @@node BFD target vector swap @@subsection Swapping functions Every target vector has function pointers used for swapping information in and out of the target representation. There are two sets of functions: one for data information, and one for header information. Each set has three sizes: 64-bit, 32-bit, and 16-bit. Each size has three actual functions: put, get unsigned, and get signed. These 18 functions are used to convert data between the host and target representations. @@node BFD target vector format @@subsection Format type dependent functions Every target vector has three arrays of function pointers which are indexed by the BFD format type. The BFD format types are as follows: @@table @@samp @@item bfd_unknown Unknown format. Not used for anything useful. @@item bfd_object Object file. @@item bfd_archive Archive file. @@item bfd_core Core file. @@end table The three arrays of function pointers are as follows: @@table @@samp @@item bfd_check_format Check whether the BFD is of a particular format (object file, archive file, or core file) corresponding to this target vector. This is called by the @@samp{bfd_check_format} function when examining an existing BFD. If the BFD matches the desired format, this function will initialize any format specific information such as the @@samp{tdata} field of the BFD. This function must be called before any other BFD target vector function on a file opened for reading. @@item bfd_set_format Set the format of a BFD which was created for output. This is called by the @@samp{bfd_set_format} function after creating the BFD with a function such as @@samp{bfd_openw}. This function will initialize format specific information required to write out an object file or whatever of the given format. This function must be called before any other BFD target vector function on a file opened for writing. @@item bfd_write_contents Write out the contents of the BFD in the given format. This is called by @@samp{bfd_close} function for a BFD opened for writing. This really should not be an array selected by format type, as the @@samp{bfd_set_format} function provides all the required information. In fact, BFD will fail if a different format is used when calling through the @@samp{bfd_set_format} and the @@samp{bfd_write_contents} arrays; fortunately, since @@samp{bfd_close} gets it right, this is a difficult error to make. @@end table @@node BFD_JUMP_TABLE macros @@subsection @@samp{BFD_JUMP_TABLE} macros @@cindex @@samp{BFD_JUMP_TABLE} Most target vectors are defined using @@samp{BFD_JUMP_TABLE} macros. These macros take a single argument, which is a prefix applied to a set of functions. The macros are then used to initialize the fields in the target vector. For example, the @@samp{BFD_JUMP_TABLE_RELOCS} macro defines three functions: @@samp{_get_reloc_upper_bound}, @@samp{_canonicalize_reloc}, and @@samp{_bfd_reloc_type_lookup}. A reference like @@samp{BFD_JUMP_TABLE_RELOCS (foo)} will expand into three functions prefixed with @@samp{foo}: @@samp{foo_get_reloc_upper_bound}, etc. The @@samp{BFD_JUMP_TABLE_RELOCS} macro will be placed such that those three functions initialize the appropriate fields in the BFD target vector. This is done because it turns out that many different target vectors can share certain classes of functions. For example, archives are similar on most platforms, so most target vectors can use the same archive functions. Those target vectors all use @@samp{BFD_JUMP_TABLE_ARCHIVE} with the same argument, calling a set of functions which is defined in @@file{archive.c}. Each of the @@samp{BFD_JUMP_TABLE} macros is mentioned below along with the description of the function pointers which it defines. The function pointers will be described using the name without the prefix which the @@samp{BFD_JUMP_TABLE} macro defines. This name is normally the same as the name of the field in the target vector structure. Any differences will be noted. @@node BFD target vector generic @@subsection Generic functions @@cindex @@samp{BFD_JUMP_TABLE_GENERIC} The @@samp{BFD_JUMP_TABLE_GENERIC} macro is used for some catch all functions which don't easily fit into other categories. @@table @@samp @@item _close_and_cleanup Free any target specific information associated with the BFD. This is called when any BFD is closed (the @@samp{bfd_write_contents} function mentioned earlier is only called for a BFD opened for writing). Most targets use @@samp{bfd_alloc} to allocate all target specific information, and therefore don't have to do anything in this function. This function pointer is typically set to @@samp{_bfd_generic_close_and_cleanup}, which simply returns true. @@item _bfd_free_cached_info Free any cached information associated with the BFD which can be recreated later if necessary. This is used to reduce the memory consumption required by programs using BFD. This is normally called via the @@samp{bfd_free_cached_info} macro. It is used by the default archive routines when computing the archive map. Most targets do not do anything special for this entry point, and just set it to @@samp{_bfd_generic_free_cached_info}, which simply returns true. @@item _new_section_hook This is called from @@samp{bfd_make_section_anyway} whenever a new section is created. Most targets use it to initialize section specific information. This function is called whether or not the section corresponds to an actual section in an actual BFD. @@item _get_section_contents Get the contents of a section. This is called from @@samp{bfd_get_section_contents}. Most targets set this to @@samp{_bfd_generic_get_section_contents}, which does a @@samp{bfd_seek} based on the section's @@samp{filepos} field and a @@samp{bfd_bread}. The corresponding field in the target vector is named @@samp{_bfd_get_section_contents}. @@item _get_section_contents_in_window Set a @@samp{bfd_window} to hold the contents of a section. This is called from @@samp{bfd_get_section_contents_in_window}. The @@samp{bfd_window} idea never really caught on, and I don't think this is ever called. Pretty much all targets implement this as @@samp{bfd_generic_get_section_contents_in_window}, which uses @@samp{bfd_get_section_contents} to do the right thing. The corresponding field in the target vector is named @@samp{_bfd_get_section_contents_in_window}. @@end table @@node BFD target vector copy @@subsection Copy functions @@cindex @@samp{BFD_JUMP_TABLE_COPY} The @@samp{BFD_JUMP_TABLE_COPY} macro is used for functions which are called when copying BFDs, and for a couple of functions which deal with internal BFD information. @@table @@samp @@item _bfd_copy_private_bfd_data This is called when copying a BFD, via @@samp{bfd_copy_private_bfd_data}. If the input and output BFDs have the same format, this will copy any private information over. This is called after all the section contents have been written to the output file. Only a few targets do anything in this function. @@item _bfd_merge_private_bfd_data This is called when linking, via @@samp{bfd_merge_private_bfd_data}. It gives the backend linker code a chance to set any special flags in the output file based on the contents of the input file. Only a few targets do anything in this function. @@item _bfd_copy_private_section_data This is similar to @@samp{_bfd_copy_private_bfd_data}, but it is called for each section, via @@samp{bfd_copy_private_section_data}. This function is called before any section contents have been written. Only a few targets do anything in this function. @@item _bfd_copy_private_symbol_data This is called via @@samp{bfd_copy_private_symbol_data}, but I don't think anything actually calls it. If it were defined, it could be used to copy private symbol data from one BFD to another. However, most BFDs store extra symbol information by allocating space which is larger than the @@samp{asymbol} structure and storing private information in the extra space. Since @@samp{objcopy} and other programs copy symbol information by copying pointers to @@samp{asymbol} structures, the private symbol information is automatically copied as well. Most targets do not do anything in this function. @@item _bfd_set_private_flags This is called via @@samp{bfd_set_private_flags}. It is basically a hook for the assembler to set magic information. For example, the PowerPC ELF assembler uses it to set flags which appear in the e_flags field of the ELF header. Most targets do not do anything in this function. @@item _bfd_print_private_bfd_data This is called by @@samp{objdump} when the @@samp{-p} option is used. It is called via @@samp{bfd_print_private_data}. It prints any interesting information about the BFD which can not be otherwise represented by BFD and thus can not be printed by @@samp{objdump}. Most targets do not do anything in this function. @@end table @@node BFD target vector core @@subsection Core file support functions @@cindex @@samp{BFD_JUMP_TABLE_CORE} The @@samp{BFD_JUMP_TABLE_CORE} macro is used for functions which deal with core files. Obviously, these functions only do something interesting for targets which have core file support. @@table @@samp @@item _core_file_failing_command Given a core file, this returns the command which was run to produce the core file. @@item _core_file_failing_signal Given a core file, this returns the signal number which produced the core file. @@item _core_file_matches_executable_p Given a core file and a BFD for an executable, this returns whether the core file was generated by the executable. @@end table @@node BFD target vector archive @@subsection Archive functions @@cindex @@samp{BFD_JUMP_TABLE_ARCHIVE} The @@samp{BFD_JUMP_TABLE_ARCHIVE} macro is used for functions which deal with archive files. Most targets use COFF style archive files (including ELF targets), and these use @@samp{_bfd_archive_coff} as the argument to @@samp{BFD_JUMP_TABLE_ARCHIVE}. Some targets use BSD/a.out style archives, and these use @@samp{_bfd_archive_bsd}. (The main difference between BSD and COFF archives is the format of the archive symbol table). Targets with no archive support use @@samp{_bfd_noarchive}. Finally, a few targets have unusual archive handling. @@table @@samp @@item _slurp_armap Read in the archive symbol table, storing it in private BFD data. This is normally called from the archive @@samp{check_format} routine. The corresponding field in the target vector is named @@samp{_bfd_slurp_armap}. @@item _slurp_extended_name_table Read in the extended name table from the archive, if there is one, storing it in private BFD data. This is normally called from the archive @@samp{check_format} routine. The corresponding field in the target vector is named @@samp{_bfd_slurp_extended_name_table}. @@item construct_extended_name_table Build and return an extended name table if one is needed to write out the archive. This also adjusts the archive headers to refer to the extended name table appropriately. This is normally called from the archive @@samp{write_contents} routine. The corresponding field in the target vector is named @@samp{_bfd_construct_extended_name_table}. @@item _truncate_arname This copies a file name into an archive header, truncating it as required. It is normally called from the archive @@samp{write_contents} routine. This function is more interesting in targets which do not support extended name tables, but I think the GNU @@samp{ar} program always uses extended name tables anyhow. The corresponding field in the target vector is named @@samp{_bfd_truncate_arname}. @@item _write_armap Write out the archive symbol table using calls to @@samp{bfd_bwrite}. This is normally called from the archive @@samp{write_contents} routine. The corresponding field in the target vector is named @@samp{write_armap} (no leading underscore). @@item _read_ar_hdr Read and parse an archive header. This handles expanding the archive header name into the real file name using the extended name table. This is called by routines which read the archive symbol table or the archive itself. The corresponding field in the target vector is named @@samp{_bfd_read_ar_hdr_fn}. @@item _openr_next_archived_file Given an archive and a BFD representing a file stored within the archive, return a BFD for the next file in the archive. This is called via @@samp{bfd_openr_next_archived_file}. The corresponding field in the target vector is named @@samp{openr_next_archived_file} (no leading underscore). @@item _get_elt_at_index Given an archive and an index, return a BFD for the file in the archive corresponding to that entry in the archive symbol table. This is called via @@samp{bfd_get_elt_at_index}. The corresponding field in the target vector is named @@samp{_bfd_get_elt_at_index}. @@item _generic_stat_arch_elt Do a stat on an element of an archive, returning information read from the archive header (modification time, uid, gid, file mode, size). This is called via @@samp{bfd_stat_arch_elt}. The corresponding field in the target vector is named @@samp{_bfd_stat_arch_elt}. @@item _update_armap_timestamp After the entire contents of an archive have been written out, update the timestamp of the archive symbol table to be newer than that of the file. This is required for a.out style archives. This is normally called by the archive @@samp{write_contents} routine. The corresponding field in the target vector is named @@samp{_bfd_update_armap_timestamp}. @@end table @@node BFD target vector symbols @@subsection Symbol table functions @@cindex @@samp{BFD_JUMP_TABLE_SYMBOLS} The @@samp{BFD_JUMP_TABLE_SYMBOLS} macro is used for functions which deal with symbols. @@table @@samp @@item _get_symtab_upper_bound Return a sensible upper bound on the amount of memory which will be required to read the symbol table. In practice most targets return the amount of memory required to hold @@samp{asymbol} pointers for all the symbols plus a trailing @@samp{NULL} entry, and store the actual symbol information in BFD private data. This is called via @@samp{bfd_get_symtab_upper_bound}. The corresponding field in the target vector is named @@samp{_bfd_get_symtab_upper_bound}. @@item _canonicalize_symtab Read in the symbol table. This is called via @@samp{bfd_canonicalize_symtab}. The corresponding field in the target vector is named @@samp{_bfd_canonicalize_symtab}. @@item _make_empty_symbol Create an empty symbol for the BFD. This is needed because most targets store extra information with each symbol by allocating a structure larger than an @@samp{asymbol} and storing the extra information at the end. This function will allocate the right amount of memory, and return what looks like a pointer to an empty @@samp{asymbol}. This is called via @@samp{bfd_make_empty_symbol}. The corresponding field in the target vector is named @@samp{_bfd_make_empty_symbol}. @@item _print_symbol Print information about the symbol. This is called via @@samp{bfd_print_symbol}. One of the arguments indicates what sort of information should be printed: @@table @@samp @@item bfd_print_symbol_name Just print the symbol name. @@item bfd_print_symbol_more Print the symbol name and some interesting flags. I don't think anything actually uses this. @@item bfd_print_symbol_all Print all information about the symbol. This is used by @@samp{objdump} when run with the @@samp{-t} option. @@end table The corresponding field in the target vector is named @@samp{_bfd_print_symbol}. @@item _get_symbol_info Return a standard set of information about the symbol. This is called via @@samp{bfd_symbol_info}. The corresponding field in the target vector is named @@samp{_bfd_get_symbol_info}. @@item _bfd_is_local_label_name Return whether the given string would normally represent the name of a local label. This is called via @@samp{bfd_is_local_label} and @@samp{bfd_is_local_label_name}. Local labels are normally discarded by the assembler. In the linker, this defines the difference between the @@samp{-x} and @@samp{-X} options. @@item _get_lineno Return line number information for a symbol. This is only meaningful for a COFF target. This is called when writing out COFF line numbers. @@item _find_nearest_line Given an address within a section, use the debugging information to find the matching file name, function name, and line number, if any. This is called via @@samp{bfd_find_nearest_line}. The corresponding field in the target vector is named @@samp{_bfd_find_nearest_line}. @@item _bfd_make_debug_symbol Make a debugging symbol. This is only meaningful for a COFF target, where it simply returns a symbol which will be placed in the @@samp{N_DEBUG} section when it is written out. This is called via @@samp{bfd_make_debug_symbol}. @@item _read_minisymbols Minisymbols are used to reduce the memory requirements of programs like @@samp{nm}. A minisymbol is a cookie pointing to internal symbol information which the caller can use to extract complete symbol information. This permits BFD to not convert all the symbols into generic form, but to instead convert them one at a time. This is called via @@samp{bfd_read_minisymbols}. Most targets do not implement this, and just use generic support which is based on using standard @@samp{asymbol} structures. @@item _minisymbol_to_symbol Convert a minisymbol to a standard @@samp{asymbol}. This is called via @@samp{bfd_minisymbol_to_symbol}. @@end table @@node BFD target vector relocs @@subsection Relocation support @@cindex @@samp{BFD_JUMP_TABLE_RELOCS} The @@samp{BFD_JUMP_TABLE_RELOCS} macro is used for functions which deal with relocations. @@table @@samp @@item _get_reloc_upper_bound Return a sensible upper bound on the amount of memory which will be required to read the relocations for a section. In practice most targets return the amount of memory required to hold @@samp{arelent} pointers for all the relocations plus a trailing @@samp{NULL} entry, and store the actual relocation information in BFD private data. This is called via @@samp{bfd_get_reloc_upper_bound}. @@item _canonicalize_reloc Return the relocation information for a section. This is called via @@samp{bfd_canonicalize_reloc}. The corresponding field in the target vector is named @@samp{_bfd_canonicalize_reloc}. @@item _bfd_reloc_type_lookup Given a relocation code, return the corresponding howto structure (@@pxref{BFD relocation codes}). This is called via @@samp{bfd_reloc_type_lookup}. The corresponding field in the target vector is named @@samp{reloc_type_lookup}. @@end table @@node BFD target vector write @@subsection Output functions @@cindex @@samp{BFD_JUMP_TABLE_WRITE} The @@samp{BFD_JUMP_TABLE_WRITE} macro is used for functions which deal with writing out a BFD. @@table @@samp @@item _set_arch_mach Set the architecture and machine number for a BFD. This is called via @@samp{bfd_set_arch_mach}. Most targets implement this by calling @@samp{bfd_default_set_arch_mach}. The corresponding field in the target vector is named @@samp{_bfd_set_arch_mach}. @@item _set_section_contents Write out the contents of a section. This is called via @@samp{bfd_set_section_contents}. The corresponding field in the target vector is named @@samp{_bfd_set_section_contents}. @@end table @@node BFD target vector link @@subsection Linker functions @@cindex @@samp{BFD_JUMP_TABLE_LINK} The @@samp{BFD_JUMP_TABLE_LINK} macro is used for functions called by the linker. @@table @@samp @@item _sizeof_headers Return the size of the header information required for a BFD. This is used to implement the @@samp{SIZEOF_HEADERS} linker script function. It is normally used to align the first section at an efficient position on the page. This is called via @@samp{bfd_sizeof_headers}. The corresponding field in the target vector is named @@samp{_bfd_sizeof_headers}. @@item _bfd_get_relocated_section_contents Read the contents of a section and apply the relocation information. This handles both a final link and a relocatable link; in the latter case, it adjust the relocation information as well. This is called via @@samp{bfd_get_relocated_section_contents}. Most targets implement it by calling @@samp{bfd_generic_get_relocated_section_contents}. @@item _bfd_relax_section Try to use relaxation to shrink the size of a section. This is called by the linker when the @@samp{-relax} option is used. This is called via @@samp{bfd_relax_section}. Most targets do not support any sort of relaxation. @@item _bfd_link_hash_table_create Create the symbol hash table to use for the linker. This linker hook permits the backend to control the size and information of the elements in the linker symbol hash table. This is called via @@samp{bfd_link_hash_table_create}. @@item _bfd_link_add_symbols Given an object file or an archive, add all symbols into the linker symbol hash table. Use callbacks to the linker to include archive elements in the link. This is called via @@samp{bfd_link_add_symbols}. @@item _bfd_final_link Finish the linking process. The linker calls this hook after all of the input files have been read, when it is ready to finish the link and generate the output file. This is called via @@samp{bfd_final_link}. @@item _bfd_link_split_section I don't know what this is for. Nothing seems to call it. The only non-trivial definition is in @@file{som.c}. @@end table @@node BFD target vector dynamic @@subsection Dynamic linking information functions @@cindex @@samp{BFD_JUMP_TABLE_DYNAMIC} The @@samp{BFD_JUMP_TABLE_DYNAMIC} macro is used for functions which read dynamic linking information. @@table @@samp @@item _get_dynamic_symtab_upper_bound Return a sensible upper bound on the amount of memory which will be required to read the dynamic symbol table. In practice most targets return the amount of memory required to hold @@samp{asymbol} pointers for all the symbols plus a trailing @@samp{NULL} entry, and store the actual symbol information in BFD private data. This is called via @@samp{bfd_get_dynamic_symtab_upper_bound}. The corresponding field in the target vector is named @@samp{_bfd_get_dynamic_symtab_upper_bound}. @@item _canonicalize_dynamic_symtab Read the dynamic symbol table. This is called via @@samp{bfd_canonicalize_dynamic_symtab}. The corresponding field in the target vector is named @@samp{_bfd_canonicalize_dynamic_symtab}. @@item _get_dynamic_reloc_upper_bound Return a sensible upper bound on the amount of memory which will be required to read the dynamic relocations. In practice most targets return the amount of memory required to hold @@samp{arelent} pointers for all the relocations plus a trailing @@samp{NULL} entry, and store the actual relocation information in BFD private data. This is called via @@samp{bfd_get_dynamic_reloc_upper_bound}. The corresponding field in the target vector is named @@samp{_bfd_get_dynamic_reloc_upper_bound}. @@item _canonicalize_dynamic_reloc Read the dynamic relocations. This is called via @@samp{bfd_canonicalize_dynamic_reloc}. The corresponding field in the target vector is named @@samp{_bfd_canonicalize_dynamic_reloc}. @@end table @@node BFD generated files @@section BFD generated files @@cindex generated files in bfd @@cindex bfd generated files BFD contains several automatically generated files. This section describes them. Some files are created at configure time, when you configure BFD. Some files are created at make time, when you build BFD. Some files are automatically rebuilt at make time, but only if you configure with the @@samp{--enable-maintainer-mode} option. Some files live in the object directory---the directory from which you run configure---and some live in the source directory. All files that live in the source directory are checked into the CVS repository. @@table @@file @@item bfd.h @@cindex @@file{bfd.h} @@cindex @@file{bfd-in3.h} Lives in the object directory. Created at make time from @@file{bfd-in2.h} via @@file{bfd-in3.h}. @@file{bfd-in3.h} is created at configure time from @@file{bfd-in2.h}. There are automatic dependencies to rebuild @@file{bfd-in3.h} and hence @@file{bfd.h} if @@file{bfd-in2.h} changes, so you can normally ignore @@file{bfd-in3.h}, and just think about @@file{bfd-in2.h} and @@file{bfd.h}. @@file{bfd.h} is built by replacing a few strings in @@file{bfd-in2.h}. To see them, search for @@samp{@@@@} in @@file{bfd-in2.h}. They mainly control whether BFD is built for a 32 bit target or a 64 bit target. @@item bfd-in2.h @@cindex @@file{bfd-in2.h} Lives in the source directory. Created from @@file{bfd-in.h} and several other BFD source files. If you configure with the @@samp{--enable-maintainer-mode} option, @@file{bfd-in2.h} is rebuilt automatically when a source file changes. @@item elf32-target.h @@itemx elf64-target.h @@cindex @@file{elf32-target.h} @@cindex @@file{elf64-target.h} Live in the object directory. Created from @@file{elfxx-target.h}. These files are versions of @@file{elfxx-target.h} customized for either a 32 bit ELF target or a 64 bit ELF target. @@item libbfd.h @@cindex @@file{libbfd.h} Lives in the source directory. Created from @@file{libbfd-in.h} and several other BFD source files. If you configure with the @@samp{--enable-maintainer-mode} option, @@file{libbfd.h} is rebuilt automatically when a source file changes. @@item libcoff.h @@cindex @@file{libcoff.h} Lives in the source directory. Created from @@file{libcoff-in.h} and @@file{coffcode.h}. If you configure with the @@samp{--enable-maintainer-mode} option, @@file{libcoff.h} is rebuilt automatically when a source file changes. @@item targmatch.h @@cindex @@file{targmatch.h} Lives in the object directory. Created at make time from @@file{config.bfd}. This file is used to map configuration triplets into BFD target vector variable names at run time. @@end table @@node BFD multiple compilations @@section Files compiled multiple times in BFD Several files in BFD are compiled multiple times. By this I mean that there are header files which contain function definitions. These header files are included by other files, and thus the functions are compiled once per file which includes them. Preprocessor macros are used to control the compilation, so that each time the files are compiled the resulting functions are slightly different. Naturally, if they weren't different, there would be no reason to compile them multiple times. This is a not a particularly good programming technique, and future BFD work should avoid it. @@itemize @@bullet @@item Since this technique is rarely used, even experienced C programmers find it confusing. @@item It is difficult to debug programs which use BFD, since there is no way to describe which version of a particular function you are looking at. @@item Programs which use BFD wind up incorporating two or more slightly different versions of the same function, which wastes space in the executable. @@item This technique is never required nor is it especially efficient. It is always possible to use statically initialized structures holding function pointers and magic constants instead. @@end itemize The following is a list of the files which are compiled multiple times. @@table @@file @@item aout-target.h @@cindex @@file{aout-target.h} Describes a few functions and the target vector for a.out targets. This is used by individual a.out targets with different definitions of @@samp{N_TXTADDR} and similar a.out macros. @@item aoutf1.h @@cindex @@file{aoutf1.h} Implements standard SunOS a.out files. In principle it supports 64 bit a.out targets based on the preprocessor macro @@samp{ARCH_SIZE}, but since all known a.out targets are 32 bits, this code may or may not work. This file is only included by a few other files, and it is difficult to justify its existence. @@item aoutx.h @@cindex @@file{aoutx.h} Implements basic a.out support routines. This file can be compiled for either 32 or 64 bit support. Since all known a.out targets are 32 bits, the 64 bit support may or may not work. I believe the original intention was that this file would only be included by @@samp{aout32.c} and @@samp{aout64.c}, and that other a.out targets would simply refer to the functions it defined. Unfortunately, some other a.out targets started including it directly, leading to a somewhat confused state of affairs. @@item coffcode.h @@cindex @@file{coffcode.h} Implements basic COFF support routines. This file is included by every COFF target. It implements code which handles COFF magic numbers as well as various hook functions called by the generic COFF functions in @@file{coffgen.c}. This file is controlled by a number of different macros, and more are added regularly. @@item coffswap.h @@cindex @@file{coffswap.h} Implements COFF swapping routines. This file is included by @@file{coffcode.h}, and thus by every COFF target. It implements the routines which swap COFF structures between internal and external format. The main control for this file is the external structure definitions in the files in the @@file{include/coff} directory. A COFF target file will include one of those files before including @@file{coffcode.h} and thus @@file{coffswap.h}. There are a few other macros which affect @@file{coffswap.h} as well, mostly describing whether certain fields are present in the external structures. @@item ecoffswap.h @@cindex @@file{ecoffswap.h} Implements ECOFF swapping routines. This is like @@file{coffswap.h}, but for ECOFF. It is included by the ECOFF target files (of which there are only two). The control is the preprocessor macro @@samp{ECOFF_32} or @@samp{ECOFF_64}. @@item elfcode.h @@cindex @@file{elfcode.h} Implements ELF functions that use external structure definitions. This file is included by two other files: @@file{elf32.c} and @@file{elf64.c}. It is controlled by the @@samp{ARCH_SIZE} macro which is defined to be @@samp{32} or @@samp{64} before including it. The @@samp{NAME} macro is used internally to give the functions different names for the two target sizes. @@item elfcore.h @@cindex @@file{elfcore.h} Like @@file{elfcode.h}, but for functions that are specific to ELF core files. This is included only by @@file{elfcode.h}. @@item elfxx-target.h @@cindex @@file{elfxx-target.h} This file is the source for the generated files @@file{elf32-target.h} and @@file{elf64-target.h}, one of which is included by every ELF target. It defines the ELF target vector. @@item freebsd.h @@cindex @@file{freebsd.h} Presumably intended to be included by all FreeBSD targets, but in fact there is only one such target, @@samp{i386-freebsd}. This defines a function used to set the right magic number for FreeBSD, as well as various macros, and includes @@file{aout-target.h}. @@item netbsd.h @@cindex @@file{netbsd.h} Like @@file{freebsd.h}, except that there are several files which include it. @@item nlm-target.h @@cindex @@file{nlm-target.h} Defines the target vector for a standard NLM target. @@item nlmcode.h @@cindex @@file{nlmcode.h} Like @@file{elfcode.h}, but for NLM targets. This is only included by @@file{nlm32.c} and @@file{nlm64.c}, both of which define the macro @@samp{ARCH_SIZE} to an appropriate value. There are no 64 bit NLM targets anyhow, so this is sort of useless. @@item nlmswap.h @@cindex @@file{nlmswap.h} Like @@file{coffswap.h}, but for NLM targets. This is included by each NLM target, but I think it winds up compiling to the exact same code for every target, and as such is fairly useless. @@item peicode.h @@cindex @@file{peicode.h} Provides swapping routines and other hooks for PE targets. @@file{coffcode.h} will include this rather than @@file{coffswap.h} for a PE target. This defines PE specific versions of the COFF swapping routines, and also defines some macros which control @@file{coffcode.h} itself. @@end table @@node BFD relocation handling @@section BFD relocation handling @@cindex bfd relocation handling @@cindex relocations in bfd The handling of relocations is one of the more confusing aspects of BFD. Relocation handling has been implemented in various different ways, all somewhat incompatible, none perfect. @@menu * BFD relocation concepts:: BFD relocation concepts * BFD relocation functions:: BFD relocation functions * BFD relocation codes:: BFD relocation codes * BFD relocation future:: BFD relocation future @@end menu @@node BFD relocation concepts @@subsection BFD relocation concepts A relocation is an action which the linker must take when linking. It describes a change to the contents of a section. The change is normally based on the final value of one or more symbols. Relocations are created by the assembler when it creates an object file. Most relocations are simple. A typical simple relocation is to set 32 bits at a given offset in a section to the value of a symbol. This type of relocation would be generated for code like @@code{int *p = &i;} where @@samp{p} and @@samp{i} are global variables. A relocation for the symbol @@samp{i} would be generated such that the linker would initialize the area of memory which holds the value of @@samp{p} to the value of the symbol @@samp{i}. Slightly more complex relocations may include an addend, which is a constant to add to the symbol value before using it. In some cases a relocation will require adding the symbol value to the existing contents of the section in the object file. In others the relocation will simply replace the contents of the section with the symbol value. Some relocations are PC relative, so that the value to be stored in the section is the difference between the value of a symbol and the final address of the section contents. In general, relocations can be arbitrarily complex. For example, relocations used in dynamic linking systems often require the linker to allocate space in a different section and use the offset within that section as the value to store. In the IEEE object file format, relocations may involve arbitrary expressions. When doing a relocatable link, the linker may or may not have to do anything with a relocation, depending upon the definition of the relocation. Simple relocations generally do not require any special action. @@node BFD relocation functions @@subsection BFD relocation functions In BFD, each section has an array of @@samp{arelent} structures. Each structure has a pointer to a symbol, an address within the section, an addend, and a pointer to a @@samp{reloc_howto_struct} structure. The howto structure has a bunch of fields describing the reloc, including a type field. The type field is specific to the object file format backend; none of the generic code in BFD examines it. Originally, the function @@samp{bfd_perform_relocation} was supposed to handle all relocations. In theory, many relocations would be simple enough to be described by the fields in the howto structure. For those that weren't, the howto structure included a @@samp{special_function} field to use as an escape. While this seems plausible, a look at @@samp{bfd_perform_relocation} shows that it failed. The function has odd special cases. Some of the fields in the howto structure, such as @@samp{pcrel_offset}, were not adequately documented. The linker uses @@samp{bfd_perform_relocation} to do all relocations when the input and output file have different formats (e.g., when generating S-records). The generic linker code, which is used by all targets which do not define their own special purpose linker, uses @@samp{bfd_get_relocated_section_contents}, which for most targets turns into a call to @@samp{bfd_generic_get_relocated_section_contents}, which calls @@samp{bfd_perform_relocation}. So @@samp{bfd_perform_relocation} is still widely used, which makes it difficult to change, since it is difficult to test all possible cases. The assembler used @@samp{bfd_perform_relocation} for a while. This turned out to be the wrong thing to do, since @@samp{bfd_perform_relocation} was written to handle relocations on an existing object file, while the assembler needed to create relocations in a new object file. The assembler was changed to use the new function @@samp{bfd_install_relocation} instead, and @@samp{bfd_install_relocation} was created as a copy of @@samp{bfd_perform_relocation}. Unfortunately, the work did not progress any farther, so @@samp{bfd_install_relocation} remains a simple copy of @@samp{bfd_perform_relocation}, with all the odd special cases and confusing code. This again is difficult to change, because again any change can affect any assembler target, and so is difficult to test. The new linker, when using the same object file format for all input files and the output file, does not convert relocations into @@samp{arelent} structures, so it can not use @@samp{bfd_perform_relocation} at all. Instead, users of the new linker are expected to write a @@samp{relocate_section} function which will handle relocations in a target specific fashion. There are two helper functions for target specific relocation: @@samp{_bfd_final_link_relocate} and @@samp{_bfd_relocate_contents}. These functions use a howto structure, but they @@emph{do not} use the @@samp{special_function} field. Since the functions are normally called from target specific code, the @@samp{special_function} field adds little; any relocations which require special handling can be handled without calling those functions. So, if you want to add a new target, or add a new relocation to an existing target, you need to do the following: @@itemize @@bullet @@item Make sure you clearly understand what the contents of the section should look like after assembly, after a relocatable link, and after a final link. Make sure you clearly understand the operations the linker must perform during a relocatable link and during a final link. @@item Write a howto structure for the relocation. The howto structure is flexible enough to represent any relocation which should be handled by setting a contiguous bitfield in the destination to the value of a symbol, possibly with an addend, possibly adding the symbol value to the value already present in the destination. @@item Change the assembler to generate your relocation. The assembler will call @@samp{bfd_install_relocation}, so your howto structure has to be able to handle that. You may need to set the @@samp{special_function} field to handle assembly correctly. Be careful to ensure that any code you write to handle the assembler will also work correctly when doing a relocatable link. For example, see @@samp{bfd_elf_generic_reloc}. @@item Test the assembler. Consider the cases of relocation against an undefined symbol, a common symbol, a symbol defined in the object file in the same section, and a symbol defined in the object file in a different section. These cases may not all be applicable for your reloc. @@item If your target uses the new linker, which is recommended, add any required handling to the target specific relocation function. In simple cases this will just involve a call to @@samp{_bfd_final_link_relocate} or @@samp{_bfd_relocate_contents}, depending upon the definition of the relocation and whether the link is relocatable or not. @@item Test the linker. Test the case of a final link. If the relocation can overflow, use a linker script to force an overflow and make sure the error is reported correctly. Test a relocatable link, whether the symbol is defined or undefined in the relocatable output. For both the final and relocatable link, test the case when the symbol is a common symbol, when the symbol looked like a common symbol but became a defined symbol, when the symbol is defined in a different object file, and when the symbol is defined in the same object file. @@item In order for linking to another object file format, such as S-records, to work correctly, @@samp{bfd_perform_relocation} has to do the right thing for the relocation. You may need to set the @@samp{special_function} field to handle this correctly. Test this by doing a link in which the output object file format is S-records. @@item Using the linker to generate relocatable output in a different object file format is impossible in the general case, so you generally don't have to worry about that. The GNU linker makes sure to stop that from happening when an input file in a different format has relocations. Linking input files of different object file formats together is quite unusual, but if you're really dedicated you may want to consider testing this case, both when the output object file format is the same as your format, and when it is different. @@end itemize @@node BFD relocation codes @@subsection BFD relocation codes BFD has another way of describing relocations besides the howto structures described above: the enum @@samp{bfd_reloc_code_real_type}. Every known relocation type can be described as a value in this enumeration. The enumeration contains many target specific relocations, but where two or more targets have the same relocation, a single code is used. For example, the single value @@samp{BFD_RELOC_32} is used for all simple 32 bit relocation types. The main purpose of this relocation code is to give the assembler some mechanism to create @@samp{arelent} structures. In order for the assembler to create an @@samp{arelent} structure, it has to be able to obtain a howto structure. The function @@samp{bfd_reloc_type_lookup}, which simply calls the target vector entry point @@samp{reloc_type_lookup}, takes a relocation code and returns a howto structure. The function @@samp{bfd_get_reloc_code_name} returns the name of a relocation code. This is mainly used in error messages. Using both howto structures and relocation codes can be somewhat confusing. There are many processor specific relocation codes. However, the relocation is only fully defined by the howto structure. The same relocation code will map to different howto structures in different object file formats. For example, the addend handling may be different. Most of the relocation codes are not really general. The assembler can not use them without already understanding what sorts of relocations can be used for a particular target. It might be possible to replace the relocation codes with something simpler. @@node BFD relocation future @@subsection BFD relocation future Clearly the current BFD relocation support is in bad shape. A wholescale rewrite would be very difficult, because it would require thorough testing of every BFD target. So some sort of incremental change is required. My vague thoughts on this would involve defining a new, clearly defined, howto structure. Some mechanism would be used to determine which type of howto structure was being used by a particular format. The new howto structure would clearly define the relocation behaviour in the case of an assembly, a relocatable link, and a final link. At least one special function would be defined as an escape, and it might make sense to define more. One or more generic functions similar to @@samp{bfd_perform_relocation} would be written to handle the new howto structure. This should make it possible to write a generic version of the relocate section functions used by the new linker. The target specific code would provide some mechanism (a function pointer or an initial conversion) to convert target specific relocations into howto structures. Ideally it would be possible to use this generic relocate section function for the generic linker as well. That is, it would replace the @@samp{bfd_generic_get_relocated_section_contents} function which is currently normally used. For the special case of ELF dynamic linking, more consideration needs to be given to writing ELF specific but ELF target generic code to handle special relocation types such as GOT and PLT. @@node BFD ELF support @@section BFD ELF support @@cindex elf support in bfd @@cindex bfd elf support The ELF object file format is defined in two parts: a generic ABI and a processor specific supplement. The ELF support in BFD is split in a similar fashion. The processor specific support is largely kept within a single file. The generic support is provided by several other files. The processor specific support provides a set of function pointers and constants used by the generic support. @@menu * BFD ELF sections and segments:: ELF sections and segments * BFD ELF generic support:: BFD ELF generic support * BFD ELF processor specific support:: BFD ELF processor specific support * BFD ELF core files:: BFD ELF core files * BFD ELF future:: BFD ELF future @@end menu @@node BFD ELF sections and segments @@subsection ELF sections and segments The ELF ABI permits a file to have either sections or segments or both. Relocatable object files conventionally have only sections. Executables conventionally have both. Core files conventionally have only program segments. ELF sections are similar to sections in other object file formats: they have a name, a VMA, file contents, flags, and other miscellaneous information. ELF relocations are stored in sections of a particular type; BFD automatically converts these sections into internal relocation information. ELF program segments are intended for fast interpretation by a system loader. They have a type, a VMA, an LMA, file contents, and a couple of other fields. When an ELF executable is run on a Unix system, the system loader will examine the program segments to decide how to load it. The loader will ignore the section information. Loadable program segments (type @@samp{PT_LOAD}) are directly loaded into memory. Other program segments are interpreted by the loader, and generally provide dynamic linking information. When an ELF file has both program segments and sections, an ELF program segment may encompass one or more ELF sections, in the sense that the portion of the file which corresponds to the program segment may include the portions of the file corresponding to one or more sections. When there is more than one section in a loadable program segment, the relative positions of the section contents in the file must correspond to the relative positions they should hold when the program segment is loaded. This requirement should be obvious if you consider that the system loader will load an entire program segment at a time. On a system which supports dynamic paging, such as any native Unix system, the contents of a loadable program segment must be at the same offset in the file as in memory, modulo the memory page size used on the system. This is because the system loader will map the file into memory starting at the start of a page. The system loader can easily remap entire pages to the correct load address. However, if the contents of the file were not correctly aligned within the page, the system loader would have to shift the contents around within the page, which is too expensive. For example, if the LMA of a loadable program segment is @@samp{0x40080} and the page size is @@samp{0x1000}, then the position of the segment contents within the file must equal @@samp{0x80} modulo @@samp{0x1000}. BFD has only a single set of sections. It does not provide any generic way to examine both sections and segments. When BFD is used to open an object file or executable, the BFD sections will represent ELF sections. When BFD is used to open a core file, the BFD sections will represent ELF program segments. When BFD is used to examine an object file or executable, any program segments will be read to set the LMA of the sections. This is because ELF sections only have a VMA, while ELF program segments have both a VMA and an LMA. Any program segments will be copied by the @@samp{copy_private} entry points. They will be printed by the @@samp{print_private} entry point. Otherwise, the program segments are ignored. In particular, programs which use BFD currently have no direct access to the program segments. When BFD is used to create an executable, the program segments will be created automatically based on the section information. This is done in the function @@samp{assign_file_positions_for_segments} in @@file{elf.c}. This function has been tweaked many times, and probably still has problems that arise in particular cases. There is a hook which may be used to explicitly define the program segments when creating an executable: the @@samp{bfd_record_phdr} function in @@file{bfd.c}. If this function is called, BFD will not create program segments itself, but will only create the program segments specified by the caller. The linker uses this function to implement the @@samp{PHDRS} linker script command. @@node BFD ELF generic support @@subsection BFD ELF generic support In general, functions which do not read external data from the ELF file are found in @@file{elf.c}. They operate on the internal forms of the ELF structures, which are defined in @@file{include/elf/internal.h}. The internal structures are defined in terms of @@samp{bfd_vma}, and so may be used for both 32 bit and 64 bit ELF targets. The file @@file{elfcode.h} contains functions which operate on the external data. @@file{elfcode.h} is compiled twice, once via @@file{elf32.c} with @@samp{ARCH_SIZE} defined as @@samp{32}, and once via @@file{elf64.c} with @@samp{ARCH_SIZE} defined as @@samp{64}. @@file{elfcode.h} includes functions to swap the ELF structures in and out of external form, as well as a few more complex functions. Linker support is found in @@file{elflink.c}. The linker support is only used if the processor specific file defines @@samp{elf_backend_relocate_section}, which is required to relocate the section contents. If that macro is not defined, the generic linker code is used, and relocations are handled via @@samp{bfd_perform_relocation}. The core file support is in @@file{elfcore.h}, which is compiled twice, for both 32 and 64 bit support. The more interesting cases of core file support only work on a native system which has the @@file{sys/procfs.h} header file. Without that file, the core file support does little more than read the ELF program segments as BFD sections. The BFD internal header file @@file{elf-bfd.h} is used for communication among these files and the processor specific files. The default entries for the BFD ELF target vector are found mainly in @@file{elf.c}. Some functions are found in @@file{elfcode.h}. The processor specific files may override particular entries in the target vector, but most do not, with one exception: the @@samp{bfd_reloc_type_lookup} entry point is always processor specific. @@node BFD ELF processor specific support @@subsection BFD ELF processor specific support By convention, the processor specific support for a particular processor will be found in @@file{elf@@var{nn}-@@var{cpu}.c}, where @@var{nn} is either 32 or 64, and @@var{cpu} is the name of the processor. @@menu * BFD ELF processor required:: Required processor specific support * BFD ELF processor linker:: Processor specific linker support * BFD ELF processor other:: Other processor specific support options @@end menu @@node BFD ELF processor required @@subsubsection Required processor specific support When writing a @@file{elf@@var{nn}-@@var{cpu}.c} file, you must do the following: @@itemize @@bullet @@item Define either @@samp{TARGET_BIG_SYM} or @@samp{TARGET_LITTLE_SYM}, or both, to a unique C name to use for the target vector. This name should appear in the list of target vectors in @@file{targets.c}, and will also have to appear in @@file{config.bfd} and @@file{configure.in}. Define @@samp{TARGET_BIG_SYM} for a big-endian processor, @@samp{TARGET_LITTLE_SYM} for a little-endian processor, and define both for a bi-endian processor. @@item Define either @@samp{TARGET_BIG_NAME} or @@samp{TARGET_LITTLE_NAME}, or both, to a string used as the name of the target vector. This is the name which a user of the BFD tool would use to specify the object file format. It would normally appear in a linker emulation parameters file. @@item Define @@samp{ELF_ARCH} to the BFD architecture (an element of the @@samp{bfd_architecture} enum, typically @@samp{bfd_arch_@@var{cpu}}). @@item Define @@samp{ELF_MACHINE_CODE} to the magic number which should appear in the @@samp{e_machine} field of the ELF header. As of this writing, these magic numbers are assigned by Caldera; if you want to get a magic number for a particular processor, try sending a note to @@email{registry@@@@caldera.com}. In the BFD sources, the magic numbers are found in @@file{include/elf/common.h}; they have names beginning with @@samp{EM_}. @@item Define @@samp{ELF_MAXPAGESIZE} to the maximum size of a virtual page in memory. This can normally be found at the start of chapter 5 in the processor specific supplement. For a processor which will only be used in an embedded system, or which has no memory management hardware, this can simply be @@samp{1}. @@item If the format should use @@samp{Rel} rather than @@samp{Rela} relocations, define @@samp{USE_REL}. This is normally defined in chapter 4 of the processor specific supplement. In the absence of a supplement, it's easier to work with @@samp{Rela} relocations. @@samp{Rela} relocations will require more space in object files (but not in executables, except when using dynamic linking). However, this is outweighed by the simplicity of addend handling when using @@samp{Rela} relocations. With @@samp{Rel} relocations, the addend must be stored in the section contents, which makes relocatable links more complex. For example, consider C code like @@code{i = a[1000];} where @@samp{a} is a global array. The instructions which load the value of @@samp{a[1000]} will most likely use a relocation which refers to the symbol representing @@samp{a}, with an addend that gives the offset from the start of @@samp{a} to element @@samp{1000}. When using @@samp{Rel} relocations, that addend must be stored in the instructions themselves. If you are adding support for a RISC chip which uses two or more instructions to load an address, then the addend may not fit in a single instruction, and will have to be somehow split among the instructions. This makes linking awkward, particularly when doing a relocatable link in which the addend may have to be updated. It can be done---the MIPS ELF support does it---but it should be avoided when possible. It is possible, though somewhat awkward, to support both @@samp{Rel} and @@samp{Rela} relocations for a single target; @@file{elf64-mips.c} does it by overriding the relocation reading and writing routines. @@item Define howto structures for all the relocation types. @@item Define a @@samp{bfd_reloc_type_lookup} routine. This must be named @@samp{bfd_elf@@var{nn}_bfd_reloc_type_lookup}, and may be either a function or a macro. It must translate a BFD relocation code into a howto structure. This is normally a table lookup or a simple switch. @@item If using @@samp{Rel} relocations, define @@samp{elf_info_to_howto_rel}. If using @@samp{Rela} relocations, define @@samp{elf_info_to_howto}. Either way, this is a macro defined as the name of a function which takes an @@samp{arelent} and a @@samp{Rel} or @@samp{Rela} structure, and sets the @@samp{howto} field of the @@samp{arelent} based on the @@samp{Rel} or @@samp{Rela} structure. This is normally uses @@samp{ELF@@var{nn}_R_TYPE} to get the ELF relocation type and uses it as an index into a table of howto structures. @@end itemize You must also add the magic number for this processor to the @@samp{prep_headers} function in @@file{elf.c}. You must also create a header file in the @@file{include/elf} directory called @@file{@@var{cpu}.h}. This file should define any target specific information which may be needed outside of the BFD code. In particular it should use the @@samp{START_RELOC_NUMBERS}, @@samp{RELOC_NUMBER}, @@samp{FAKE_RELOC}, @@samp{EMPTY_RELOC} and @@samp{END_RELOC_NUMBERS} macros to create a table mapping the number used to identify a relocation to a name describing that relocation. While not a BFD component, you probably also want to make the binutils program @@samp{readelf} parse your ELF objects. For this, you need to add code for @@code{EM_@@var{cpu}} as appropriate in @@file{binutils/readelf.c}. @@node BFD ELF processor linker @@subsubsection Processor specific linker support The linker will be much more efficient if you define a relocate section function. This will permit BFD to use the ELF specific linker support. If you do not define a relocate section function, BFD must use the generic linker support, which requires converting all symbols and relocations into BFD @@samp{asymbol} and @@samp{arelent} structures. In this case, relocations will be handled by calling @@samp{bfd_perform_relocation}, which will use the howto structures you have defined. @@xref{BFD relocation handling}. In order to support linking into a different object file format, such as S-records, @@samp{bfd_perform_relocation} must work correctly with your howto structures, so you can't skip that step. However, if you define the relocate section function, then in the normal case of linking into an ELF file the linker will not need to convert symbols and relocations, and will be much more efficient. To use a relocation section function, define the macro @@samp{elf_backend_relocate_section} as the name of a function which will take the contents of a section, as well as relocation, symbol, and other information, and modify the section contents according to the relocation information. In simple cases, this is little more than a loop over the relocations which computes the value of each relocation and calls @@samp{_bfd_final_link_relocate}. The function must check for a relocatable link, and in that case normally needs to do nothing other than adjust the addend for relocations against a section symbol. The complex cases generally have to do with dynamic linker support. GOT and PLT relocations must be handled specially, and the linker normally arranges to set up the GOT and PLT sections while handling relocations. When generating a shared library, random relocations must normally be copied into the shared library, or converted to RELATIVE relocations when possible. @@node BFD ELF processor other @@subsubsection Other processor specific support options There are many other macros which may be defined in @@file{elf@@var{nn}-@@var{cpu}.c}. These macros may be found in @@file{elfxx-target.h}. Macros may be used to override some of the generic ELF target vector functions. Several processor specific hook functions which may be defined as macros. These functions are found as function pointers in the @@samp{elf_backend_data} structure defined in @@file{elf-bfd.h}. In general, a hook function is set by defining a macro @@samp{elf_backend_@@var{name}}. There are a few processor specific constants which may also be defined. These are again found in the @@samp{elf_backend_data} structure. I will not define the various functions and constants here; see the comments in @@file{elf-bfd.h}. Normally any odd characteristic of a particular ELF processor is handled via a hook function. For example, the special @@samp{SHN_MIPS_SCOMMON} section number found in MIPS ELF is handled via the hooks @@samp{section_from_bfd_section}, @@samp{symbol_processing}, @@samp{add_symbol_hook}, and @@samp{output_symbol_hook}. Dynamic linking support, which involves processor specific relocations requiring special handling, is also implemented via hook functions. @@node BFD ELF core files @@subsection BFD ELF core files @@cindex elf core files On native ELF Unix systems, core files are generated without any sections. Instead, they only have program segments. When BFD is used to read an ELF core file, the BFD sections will actually represent program segments. Since ELF program segments do not have names, BFD will invent names like @@samp{segment@@var{n}} where @@var{n} is a number. A single ELF program segment may include both an initialized part and an uninitialized part. The size of the initialized part is given by the @@samp{p_filesz} field. The total size of the segment is given by the @@samp{p_memsz} field. If @@samp{p_memsz} is larger than @@samp{p_filesz}, then the extra space is uninitialized, or, more precisely, initialized to zero. BFD will represent such a program segment as two different sections. The first, named @@samp{segment@@var{n}a}, will represent the initialized part of the program segment. The second, named @@samp{segment@@var{n}b}, will represent the uninitialized part. ELF core files store special information such as register values in program segments with the type @@samp{PT_NOTE}. BFD will attempt to interpret the information in these segments, and will create additional sections holding the information. Some of this interpretation requires information found in the host header file @@file{sys/procfs.h}, and so will only work when BFD is built on a native system. BFD does not currently provide any way to create an ELF core file. In general, BFD does not provide a way to create core files. The way to implement this would be to write @@samp{bfd_set_format} and @@samp{bfd_write_contents} routines for the @@samp{bfd_core} type; see @@ref{BFD target vector format}. @@node BFD ELF future @@subsection BFD ELF future The current dynamic linking support has too much code duplication. While each processor has particular differences, much of the dynamic linking support is quite similar for each processor. The GOT and PLT are handled in fairly similar ways, the details of -Bsymbolic linking are generally similar, etc. This code should be reworked to use more generic functions, eliminating the duplication. Similarly, the relocation handling has too much duplication. Many of the @@samp{reloc_type_lookup} and @@samp{info_to_howto} functions are quite similar. The relocate section functions are also often quite similar, both in the standard linker handling and the dynamic linker handling. Many of the COFF processor specific backends share a single relocate section function (@@samp{_bfd_coff_generic_relocate_section}), and it should be possible to do something like this for the ELF targets as well. The appearance of the processor specific magic number in @@samp{prep_headers} in @@file{elf.c} is somewhat bogus. It should be possible to add support for a new processor without changing the generic support. The processor function hooks and constants are ad hoc and need better documentation. @@node BFD glossary @@section BFD glossary @@cindex glossary for bfd @@cindex bfd glossary This is a short glossary of some BFD terms. @@table @@asis @@item a.out The a.out object file format. The original Unix object file format. Still used on SunOS, though not Solaris. Supports only three sections. @@item archive A collection of object files produced and manipulated by the @@samp{ar} program. @@item backend The implementation within BFD of a particular object file format. The set of functions which appear in a particular target vector. @@item BFD The BFD library itself. Also, each object file, archive, or executable opened by the BFD library has the type @@samp{bfd *}, and is sometimes referred to as a bfd. @@item COFF The Common Object File Format. Used on Unix SVR3. Used by some embedded targets, although ELF is normally better. @@item DLL A shared library on Windows. @@item dynamic linker When a program linked against a shared library is run, the dynamic linker will locate the appropriate shared library and arrange to somehow include it in the running image. @@item dynamic object Another name for an ELF shared library. @@item ECOFF The Extended Common Object File Format. Used on Alpha Digital Unix (formerly OSF/1), as well as Ultrix and Irix 4. A variant of COFF. @@item ELF The Executable and Linking Format. The object file format used on most modern Unix systems, including GNU/Linux, Solaris, Irix, and SVR4. Also used on many embedded systems. @@item executable A program, with instructions and symbols, and perhaps dynamic linking information. Normally produced by a linker. @@item LMA Load Memory Address. This is the address at which a section will be loaded. Compare with VMA, below. @@item NLM NetWare Loadable Module. Used to describe the format of an object which be loaded into NetWare, which is some kind of PC based network server program. @@item object file A binary file including machine instructions, symbols, and relocation information. Normally produced by an assembler. @@item object file format The format of an object file. Typically object files and executables for a particular system are in the same format, although executables will not contain any relocation information. @@item PE The Portable Executable format. This is the object file format used for Windows (specifically, Win32) object files. It is based closely on COFF, but has a few significant differences. @@item PEI The Portable Executable Image format. This is the object file format used for Windows (specifically, Win32) executables. It is very similar to PE, but includes some additional header information. @@item relocations Information used by the linker to adjust section contents. Also called relocs. @@item section Object files and executable are composed of sections. Sections have optional data and optional relocation information. @@item shared library A library of functions which may be used by many executables without actually being linked into each executable. There are several different implementations of shared libraries, each having slightly different features. @@item symbol Each object file and executable may have a list of symbols, often referred to as the symbol table. A symbol is basically a name and an address. There may also be some additional information like the type of symbol, although the type of a symbol is normally something simple like function or object, and should be confused with the more complex C notion of type. Typically every global function and variable in a C program will have an associated symbol. @@item target vector A set of functions which implement support for a particular object file format. The @@samp{bfd_target} structure. @@item Win32 The current Windows API, implemented by Windows 95 and later and Windows NT 3.51 and later, but not by Windows 3.1. @@item XCOFF The eXtended Common Object File Format. Used on AIX. A variant of COFF, with a completely different symbol table implementation. @@item VMA Virtual Memory Address. This is the address a section will have when an executable is run. Compare with LMA, above. @@end table @@node Index @@unnumberedsec Index @@printindex cp @@contents @@bye @ 1.1.1.1 log @import 7.3.1 @ text @@ 1.1.1.1.8.1 log @Rebase to HEAD as of a few days ago. @ text @d3 1 a3 1 @@c 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2009, 2013 d948 1 a948 1 in the source directory are checked into the git repository. @ 1.1.1.1.18.1 log @Rebase. @ text @d3 1 a3 1 @@c 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2009, 2013 d948 1 a948 1 in the source directory are checked into the git repository. @ 1.1.1.2 log @ChangeLog: 2013-12-19 Keven Boell * cp-namespace.c (cp_lookup_nested_symbol): Enable nested lookups for fortran modules. * dwarf2read.c (read_module): Add fortran module to the symbol table. (add_partial_symbol, add_partial_module): Add fortran module to the partial symbol table. (new_symbol_full): Create full symbol for fortran module. * f-exp.y (yylex): Add new module domain to be parsed. * symtab.h: New domain for fortran modules. 2013-12-19 Keven Boell * f-exp.y (yylex): Add domain array to enable lookup in multiple domains. Loop over lookup domains and try to find requested symbol. Add STRUCT_DOMAIN to lookup domains to be able to query for user defined types. 2013-12-13 Francois-Xavier Coudert * configure.ac: Add user-friendly check for native x86_64-linux multilibs. * configure: Regenerate. 2013-11-23 Alan Modra * config.sub, config.guess: Import from upstream. 2013-11-07 Thomas Schwinge * Makefile.in: Regenerate. * Makefile.tpl: Fix typo. * Makefile.in: Regenerate partially. 2013-11-04 Balaji V. Iyer * configure.ac: Added libcilkrts to noconfig list when C++ is not supported. * configure: Regenerated. 2013-10-30 Jason Merrill * Makefile.tpl (STAGE1_CONFIGURE_FLAGS): Pass --disable-build-format-warnings. 2013-10-29 Balaji V. Iyer * Makefile.def: Add libcilkrts to target_modules. Make libcilkrts depend on libstdc++ and libgcc. * configure: Regenerate. * configure.ac: Added libcilkrts to target binaries. Also, restrict libcilkrts for POSIX and i*86, and x86_64 architectures. * Makefile.in: Added libcilkrts related fields to support building it. 2013-10-26 Jeff Law * Makefile.def (target_modules): Remove libmudflap (languages): Remove check-target-libmudflap). * Makefile.in: Rebuilt. * Makefile.tpl (check-target-libmudflap-c++): Remove. * configure.ac (target_libraries): Remove target-libmudflap. Remove checks which disabled libmudflap on some systems. * configure: Rebuilt. * libmudflap: Directory removed. 2013-10-16 Jan-Benedict Glaw * configure.ac: Update from GCC. * configure: Regenerate. 2013-10-15 Hans-Peter Nilsson * src-release (do-proto-toplevel): Support subdir-path-prefixed files in SUPPORT_FILES. (SIM_SUPPORT_DIRS): New variable. (sim.tar.bz2): New rule. 2013-10-08 Jan-Benedict Glaw * configure.ac: Update from GCC. * configure: Regenerate. 2013-10-01 Jeff Johnston * COPYING.NEWLIB: Update with new copyright. 2013-09-21 Jan-Benedict Glaw * configure.ac: Update from GCC. * configure: Regenerate. 2013-09-20 Alan Modra * libtool.m4 (_LT_ENABLE_LOCK ): Remove non-canonical ppc host match. Support little-endian powerpc linux hosts. 2013-08-16 Joel Brobecker * src-release (VER): When using $(TOOL)/common/create-version.sh, strip the "-cvs" suffix from the version number if present. 2013-08-12 Jan-Benedict Glaw * configure.ac: Sync with GCC repo. * Makefile.def: Ditto. * configure: Regenerate. * Makefile.in: Ditto. 2013-07-22 Joel Brobecker * src-release (VER): Use $(TOOL)/common/create-version.sh if it exists. 2013-06-22 Richard Sandiford * configure.ac (mips*-*-bsd*, mips*-*-ultrix*, mips*-*-osf*) (mips*-*-ecoff*, mips*-*-pe*, mips*-*-irix* [v4 and earlier]) (mips*-*-lnews*, mips*-*-riscos*): Add gas and ld to noconfigdirs. * configure: Regenerate. 2013-06-01 George Thomas * include/opcode/avr.h: Rename AVR_ISA_XCH to AVR_ISA_RMW. Remove from AVR_ISA_XMEGA and add new AVR_ISA_XMEGAU 2013-05-06 Sandra Loosemore * COPYING.NEWLIB: Add Altera Corporation copyright. 2013-04-29 Jan-Benedict Glaw * config.guess: Update from config repo. * config.sub: Ditto. 2013-04-22 Jan-Benedict Glaw * Makefile.def: Sync with GCC. * Makefile.in: Regenerate. 2013-04-22 Jan-Benedict Glaw * configure.ac: Sync with GCC. * configure: Regenerate. 2013-03-22 Mike Frysinger * src-release (VER): Change bfd/configure.in sed to use the new `bfd/configure --version` output. @ text @d3 1 a3 1 @@c 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2009, 2013 d948 1 a948 1 in the source directory are checked into the git repository. @ 1.1.1.3 log @import new gdb @ text @d2 3 a4 1 @@c Copyright (C) 1988-2015 Free Software Foundation, Inc. d19 3 a21 1 Copyright @@copyright{} 1988-2015 Free Software Foundation, Inc. d1555 1 a1555 1 have to appear in @@file{config.bfd} and @@file{configure.ac}. Define @ 1.1.1.3.2.1 log @Sync with HEAD @ text @d2 1 a2 1 @@c Copyright (C) 1988-2016 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2016 Free Software Foundation, Inc. @ 1.1.1.4 log @import gdb-7.12 @ text @d2 1 a2 1 @@c Copyright (C) 1988-2016 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2016 Free Software Foundation, Inc. @ 1.1.1.5 log @Import gdb-8.0.1 @ text @d2 1 a2 1 @@c Copyright (C) 1988-2017 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2017 Free Software Foundation, Inc. @ 1.1.1.5.4.1 log @Sync with HEAD @ text @d2 1 a2 1 @@c Copyright (C) 1988-2019 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2019 Free Software Foundation, Inc. d321 1 a321 1 how the target vector is named in command-line options for tools which d339 6 d1107 7 d1116 19 a1134 1 Used by all netbsd aout targets. Several other files include it. d1189 2 a1190 1 section as the value to store. d1829 5 @ 1.1.1.6 log @ May 11th, 2019: GDB 8.3 Released! The latest version of GDB, version 8.3, is available for download. This version of GDB includes the following changes and enhancements: + Support for new native configurations (also available as a target configuration): o RISC-V GNU/Linux (riscv*-*-linux*) o RISC-V FreeBSD (riscv*-*-freebsd*) + Support for new target configurations: o CSKY ELF (csky*-*-elf) o CSKY GNU/Linux (csky*-*-linux) o NXP S12Z ELF (s12z-*-elf) o OpenRISC GNU/Linux (or1k*-*-linux*) + Native Windows debugging is only supported on Windows XP or later. + The Python API in GDB now requires Python 2.6 or later. + GDB now supports terminal styling for the CLI and TUI. Source highlighting is also supported by building GDB with GNU Highlight. + Experimental support for compilation and injection of C++ source code into the inferior (requires GCC 7.1 or higher, built with libcp1.so). + GDB and GDBserver now support IPv6 connections. + Target description support on RISC-V targets. + Various enhancements to several commands: o "frame", "select-frame" and "info frame" commands o "info functions", "info types", "info variables" o "info thread" o "info proc" o System call alias catchpoint support on FreeBSD o "target remote" support for Unix Domain sockets. + Support for displaying all files opened by a process + DWARF index cache: GDB can now automatically save indices of DWARF symbols on disk to speed up further loading of the same binaries. + Various GDB/MI enhancements. + GDBserver on PowerPC GNU/Linux now supports access to the PPR, DSCR, TAR, EBB/PMU, and HTM registers. + Ada task switching support when debugging programs built with the Ravenscar profile added to aarch64-elf. + GDB in batch mode now exits with status 1 if the last executed command failed. + Support for building GDB with GCC's Undefined Behavior Sanitizer. See the NEWS file for a more complete and detailed list of what this release includes. February 27th, 2019: GDB 8.3 branch created The GDB 8.3 branch (gdb-8.3-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-8.3-branch ssh://sourceware.org/git/binutils-gdb.git December 23rd, 2018: GDB 8.2.1 Released! The latest version of GDB, version 8.2.1, is available for download. This is a minor corrective release over GDB 8.2, fixing the following issues: + PR build/23516 (gdb build error under msys+mingw: strip can't handle gdb-add-index.exe) + PR build/23623 (install-strip fails) + PR rust/23626 (gdb crashes in upstream rust nil-enum test) + PR rust/23650 (rust field name access error mentions "foo") + PR gdb/23663 (gdb 8.1.1: undefined rpl_stat function with musl toolchains) + PR python/23669 (gdb.execute("show commands") doesn't work) + PR python/23714 (Command repetition stops working after gdb.execute) + PR gdb/23838 (8.2 regression for invalid -data-directory) + PR gdb/23974 ("info os" crash when specifying invalid object) + PR gdb/23999 (SYMBOL_LANGUAGE assertion failure on AIX) + PR gdb/24003 (Error when binary searching CUs for a specific DIE when using DWZ) September 5th, 2018: GDB 8.2 Released! The latest version of GDB, version 8.2, is available for download. This version of GDB includes the following changes and enhancements: + Support for the following target has been added: o RiscV ELF (riscv*-*-elf) + Support for following targets and native configurations has been removed: o m88k running OpenBSD (m88*-*-openbsd*) o SH-5/SH64 ELF (sh64-*-elf*) o SH-5/SH64 (sh*) o SH-5/SH64 running GNU/Linux (sh*-*-linux*) o SH-5/SH64 running OpenBSD (sh*-*-openbsd*) + Various Python API enhancements + Aarch64/Linux enhancements: o SVE support. o Hardware watchpoints improvements for entities stored at unaligned addresses. # New "c" response to disable the pager for the rest of the current command. # C expressions can now use _Alignof, and C++ expressions can now use alignof. # Improved flexibility for loading symbol files. # The 'info proc' command nows works on running processes on FreeBSD systems as well as core files created on FreeBSD systems. # A new --enable-codesign=CERT configure option to automatically codesign GDB after build (useful on MacOS X). See the NEWS file for a more complete and detailed list of what this release includes. July 31st, 2018: GDB 8.1.1 Released! The latest version of GDB, version 8.1.1, is available for download. This is a minor corrective release over GDB 8.1, fixing the following issues: # PR gdb/22824 (misleading description of new rbreak Python function in GDB 8.1 NEWS file) # PR gdb/22849 (ctrl-c doesn't work in extended-remote) # PR gdb/22907 ([Regression] gdbserver doesn't work with filename-only binaries) # PR gdb/23028 (inconsistent disassemble of vcvtpd2dq) # PR gdb/23053 (Fix -D_GLIBCXX_DEBUG gdb-add-index regression) # PR gdb/23127 ([AArch64] GDB cannot be used for debugging software that uses high Virtual Addresses) # PR server/23158 (gdbserver no longer functional on Windows) # PR breakpoints/23210 ([8.1/8.2 Regression] Bogus Breakpoint address adjusted from 0xf7fe7dd3 to 0xfffffffff7fe7dd3) July 4th, 2018: GDB 8.2 branch created The GDB 8.2 branch (gdb-8.2-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-8.2-branch ssh://sourceware.org/git/binutils-gdb.git January 31st, 2018: GDB 8.1 Released! The latest version of GDB, version 8.1, is available for download. Changes in this release include: # Breakpoints on C++ functions are now set on all scopes by default ("wild" matching); # Support for inserting breakpoints on functions marked with C++ ABI tags; # Target floating-point arithmetic emulation during expression evaluation (requires MPFR 3.1 or later); # Various Python Scripting enhancements; # Improved Rust support; in particular, Trait objects can now be inspected when debugging Rust code; # GDB no longer makes assumptions about the type of symbols without debugging information to avoid producing erroneous and often confusing results; # The 'enable' and 'disable' commands now accept a range of breakpoint locations; # New 'starti' command to start the program at the first instruction; # New 'rbreak' command to insert a number of breakpoints via a regular expression pattern (requires Python); # The 'ptype' command now supports printing the offset and size of the fields in a struct; # The 'gcore' command now supports dumping all the memory mappings ('-a' command-line option); # New shortcuts for TUI Single-Key mode: 'i' for stepi, and 'o' for nexti; # GDBserver enhancements: @@ Support for transmitting environment variables to GDBserver; @@ Support for starting inferior processes with a specified initial working directory; @@ On Unix systems, support for globbing expansion and variable substitution of inferior command-line arguments; # Various completion enhancements; # The command used to compile and inject code with the 'compile' command is now configurable; # New '--readnever' command-line option to speed the GDB startup when debugging information is not needed; # Support for the following new native configurations: @@ FreeBSD/aarch64 (aarch64*-*-freebsd*); @@ FreeBSD/arm (arm*-*-freebsd*); # Support for the following new targets: @@ FreeBSD/aarch64 (aarch64*-*-freebsd*); @@ FreeBSD/arm (arm*-*-freebsd*); @@ OpenRISC ELF (or1k*-*-elf) # Removed support for the following targets and native configurations: @@ Solaris2/x86 (i?86-*-solaris2.[0-9]); @@ Solaris2/sparc (sparc*-*-solaris2.[0-9]); See the NEWS file for a more complete and detailed list of what this release includes. January 5th, 2018: GDB 8.1 branch created The GDB 8.1 branch (gdb-8.1-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-8.1-branch ssh://sourceware.org/git/binutils-gdb.git November 1st, 2017: Debugging Tools Devroom at FOSDEM 2018 We will have a Debugging Tools Devroom at FOSDEM 2018. The Call for Participation has recently been announced. The Devroom is on the first of the two FOSDEM days, on Saturday 3 Feb 2018. See you all at FOSDEM in Brussels! September 7th, 2017: GDB 8.0.1 Released! The latest version of GDB, version 8.0.1, is available for download. This is a minor corrective release over GDB 8.0, fixing the following issues: # PR breakpoint/21886 (Compressed MIPS code debugging impossible due to memory breakpoint misplacement) # PR symtab/22002 (Assertion on debuggee built with -gdwarf-5 -fdebug-types-section) GDB News (p6 of 30) # PR symtab/22003 (Incompatibility with -gdwarf-5 - DW_FORM_implicit_const) # PR gdb/22046 (Regression on older kernels for T (stopped) processes) # PR sim/20863 (gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD) # PR breakpoint/21555 ("error re-setting breakpoint" on PIE executables) # PR tdep/21717 ("print $fpscr" says "" until some VFP data register is printed) # PR exp/21827 (Regression: gdb command lookup became case-sensitive; but definitions are forced into lowercase) # PR remote/22021 (Multi-arch exec fails with a remote target) @ text @d2 1 a2 1 @@c Copyright (C) 1988-2019 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2019 Free Software Foundation, Inc. d321 1 a321 1 how the target vector is named in command-line options for tools which d339 6 d1107 7 d1116 19 a1134 1 Used by all netbsd aout targets. Several other files include it. d1189 2 a1190 1 section as the value to store. d1829 5 @ 1.1.1.7 log @Import head of gdb as of 2020-09-14 requested by Kamil 2020-07-24 Aaron Merey * configure: Rebuild. * configure.ac: Remove AC_DEBUGINFOD. 2020-07-04 Nick Clifton Binutils 2.35 branch created. 2020-04-21 Stephen Casner PR 25830 * configure.ac (noconfigdirs): Exclude gdb & gprof for pdp11. * configure: Rebuild. 2020-03-12 Tom Tromey * Makefile.in: Rebuild. * Makefile.def (gdbserver): Depend on gdbsupport. 2020-03-12 Tom Tromey * Makefile.in: Rebuild. * Makefile.def (gdbsupport): Don't depend on bfd. 2020-03-12 Tom Tromey * Makefile.in: Rebuild. * Makefile.def (gdbsupport): Depend on intl. 2020-02-17 Tom Tromey * configure: Rebuild. * configure.ac (configdirs): Add gnulib and gdbsupport when building gdbserver. 2020-02-14 Tom Tromey * Makefile.in: Rebuild. * Makefile.def: Make gdbserver require gnulib and libiberty. 2020-02-07 Tom Tromey Pedro Alves * src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver. * gdbserver: New directory, moved from gdb/gdbserver. * configure.ac (host_tools): Add gdbserver. Only build gdbserver on certain systems. * Makefile.in, configure: Rebuild. * Makefile.def (host_modules, dependencies): Add gdbserver. * MAINTAINERS: Add gdbserver. 2020-01-28 Sergio Durigan Junior * src-release.sh (getver): Look for gdbsupport's create-version.sh script at the current directory if tool is "gdb". 2020-01-19 Simon Marchi * remote-sim.c (gdbsim_target::wait): Return sim_data->remote_sim_ptid instead of inferior_ptid. 2020-01-18 Nick Clifton Binutils 2.34 branch created. 2020-01-18 Nick Clifton Synchronize top level configure files with master version: 2020-01-01 Ben Elliston * config.guess: Update copyright years. * config.sub: Likewise. 2019-12-21 Ben Elliston * config.guess (set_cc_for_build): Prevent multiple calls by checking if $tmp is already set. We can't check CC_FOR_BUILD as the user may set it externally. Thanks to Torbjörn Granlund for the bug report. 2019-12-21 Torbjörn Granlund * config.guess (alpha:Linux:*:*): Guard against missing /proc/cpuinfo by redirecting standard error to /dev/null. 2019-09-12 Daniel Bittman * config.guess (*:Twizzler:*:*): New. * config.sub (-twizzler*): New. 2019-07-24 Ben Elliston * config.guess (mips:OSF1:*.*): Whitespace cleanup. 2019-06-30 Ben Elliston * config.sub (case $os): Match nsk* and powerunix. Don't later match nsk* and set os=nsk which removes the OS version number. 2019-06-30 Ben Elliston * config.sub: Recognise os108*. 2019-06-26 Ben Elliston * config.sub (hp300): Set $os to hpux. 2019-06-26 Ben Elliston * config.sub (vsta): Move into alphabetical order. 2019-06-10 Ben Elliston * config.guess (*:OS108:*:*): Recognise new OS. 2019-05-28 Ben Elliston * config.guess (*:Darwin:*:*): Run xcode-select to determine if a system compiler is installed. If not, do not run set_cc_for_build, as the default cc will open a dialog box asking to install Xcode. If no C compiler is available, guess based on uname -p and uname -m. 2019-05-28 Ben Elliston * config.guess (*:Darwin:*:*): Simplify UNAME_PROCESSOR. 2020-01-17 Simon Marchi * Makefile.def: Add dependencies of all-gdbsupport on all-bfd. * Makefile.in: Re-generate. 2020-01-14 Tom Tromey * src-release.sh (GDB_SUPPORT_DIRS): Add gdbsupport. * MAINTAINERS: Add gdbsupport. * configure: Rebuild. * configure.ac (configdirs): Add gdbsupport. * gdbsupport: New directory, move from gdb/gdbsupport. * Makefile.def (host_modules, dependencies): Add gnulib. * Makefile.in: Rebuild. 2020-01-09 Aaron Merey * config/debuginfod.m4: New file. Add macro AC_DEBUGINFOD. Adds new configure option --with-debuginfod. * configure: Regenerate. * configure.ac: Call AC_DEBUGINFOD. 2019-12-26 Christian Biesinger * .gitignore: Add perf.data and perf.data.old. 2019-10-17 Sergio Durigan Junior * src-release.sh (GDB_SUPPORT_DIRS): Add libctf. 2019-10-17 Alan Modra PR 29 * src-release.sh (getver): Replace "head -1" with "head -n 1". 2019-07-30 Nick Alcock * Makefile.def (host_modules): libctf is no longer no_install. * Makefile.in: Regenerated. 2019-07-13 Nick Alcock * Makefile.def (dependencies): all-ld depends on all-libctf. * Makefile.in: Regenerated. 2019-09-09 Phil Blundell binutils 2.33 branch created 2019-08-19 Tom Tromey * configure: Rebuild. * configure.ac: Add --with-static-standard-libraries. 2019-08-09 Nick Clifton * libiberty: Sync with gcc. Bring in: 2019-08-08 Martin Liska PR bootstrap/91352 * lrealpath.c (is_valid_fd): New function. 2019-07-24 Martin Liska PR lto/91228 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Find first '\0' starting from gnu_lto + 1. 2019-07-12 Ren Kimura * simple-object-elf.c (simple_object_elf_match): Check zero value shstrndx. This fixes a Bug 90924. 2019-07-22 Martin Liska * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Do not search for gnu_lto_v1, but search for first '\0'. 2019-07-18 Eduard-Mihai Burtescu * cplus-dem.c: Include rust-demangle.h. * rust-demangle.c: Include rust-demangle.h. * rust-demangle.h: New file. 2019-05-31 Michael Forney * cp-demangle.c: Don't define CP_DYNAMIC_ARRAYS if __STDC_NO_VLA__ is non-zero. 2019-04-30 Ben L * d-demangle.c (dlang_parse_assocarray): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. * d-demangle.c (dlang_parse_tuple): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. * d-demangle.c (dlang_parse_structlit): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. * d-demangle.c (dlang_parse_arrayliteral): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. * d-demangle.c (dlang_parse_integer): Fix stack underflow. * testsuite/d-demangle-expected: Add testcase. * cp-demangle (d_print_comp_inner): Guard against a NULL 'typed_name'. * testsuite/demangle-expected: Add testcase. * cp-demangle.c (d_encoding): Guard against NULL return values from d_right (dc). * testsuite/demangle-expected: Add testcase. 2019-04-29 Ben L * cp-demangle.c (d_expression_1): Don't peek ahead unless the current char is valid. * testsuite/demangle-expected: Add testcase. 2019-04-10 Nick Clifton PR 89394 * cp-demangle.c (cplus_demangle_fill_name): Reject negative lengths. (d_count_templates_scopes): Replace num_templates and num_scopes parameters with a struct d_print_info pointer parameter. Adjust body of the function accordingly. Add recursion counter and check that the recursion limit is not reached. (d_print_init): Pass dpi parameter to d_count_templates_scopes. Reset recursion counter afterwards, unless the recursion limit was reached. 2019-07-13 Joel Brobecker * src-release (getver): If $tool/gdbsupport/create-version.sh exists, use that to determine the version number. 2019-06-21 Andreas Schwab * src-release.sh (GDB_SUPPORT_DIRS): Add gnulib. 2019-06-14 Tom Tromey * MAINTAINERS: Add gnulib. * gnulib: New directory, move from gdb/gnulib. * configure.ac (host_libs): Add gnulib. * configure: Rebuild. * Makefile.def (host_modules, dependencies): Add gnulib. * Makefile.in: Rebuild. 2019-06-03 Nick Clifton Revert: 2019-05-29 Nick Clifton * configure.ac (noconfigdirs): Add libctf if the target does not use the ELF file format. * configure: Regenerate. 2019-05-29 Nick Clifton * src-release.sh (do_proto_toplev): Add libctf to list of directories that can be disabled. 2019-05-29 Nick Clifton * configure.ac (noconfigdirs): Add libctf if the target does not use the ELF file format. * configure: Regenerate. 2019-05-28 Nick Alcock * Makefile.def (dependencies): configure-libctf depends on all-bfd and all its deps. * Makefile.in: Regenerated. 2019-05-28 Nick Alcock * MAINTAINERS: Add libctf. 2019-05-28 Nick Alcock * Makefile.def (host_modules): Add libctf. * Makefile.def (dependencies): Likewise. libctf depends on zlib, libiberty, and bfd. * Makefile.in: Regenerated. * configure.ac (host_libs): Add libctf. * configure: Regenerated. 2019-05-23 Jose E. Marchesi * config.guess: Synchronize with config project master sources. * config.sub: Likewise. * readline/support/config.guess: Likewise. * readline/support/config.sub: Likewise. 2019-04-10 Nick Clifton * libiberty: Sync with gcc. Bring in: 2019-04-10 Nick Clifton PR 89394 * cp-demangle.c (cplus_demangle_fill_name): Reject negative lengths. (d_count_templates_scopes): Replace num_templates and num_scopes parameters with a struct d_print_info pointer parameter. Adjust body of the function accordingly. Add recursion counter and check that the recursion limit is not reached. (d_print_init): Pass dpi parameter to d_count_templates_scopes. Reset recursion counter afterwards, unless the recursion limit was reached. 2018-06-24 Nick Clifton 2.32 branch created. 2019-01-14 Rainer Orth Merge from GCC: PR target/88535 * config.guess: Import upstream version 2019-01-03. * config.sub: Import upstream version 2019-01-01. 2019-01-10 Nick Clifton * libiberty: Sync with gcc. Bring in: 2019-01-09 Sandra Loosemore PR other/16615 * cp-demangle.c: Mechanically replace "can not" with "cannot". * floatformat.c: Likewise. * strerror.c: Likewise. 2018-12-22 Jason Merrill Remove support for demangling GCC 2.x era mangling schemes. * cplus-dem.c: Remove cplus_mangle_opname, cplus_demangle_opname, internal_cplus_demangle, and all subroutines. (libiberty_demanglers): Remove entries for ancient GNU (pre-3.0), Lucid, ARM, HP, and EDG demangling styles. (cplus_demangle): Remove 'work' variable. Don't call internal_cplus_demangle. 2019-01-03 Дилян Палаузов * configure.ac: Don't configure readline if --with-system-readline is used. * configure: Re-generate. @ text @d2 1 a2 1 @@c Copyright (C) 1988-2020 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2020 Free Software Foundation, Inc. @ 1.1.1.8 log @Import gdb-13.2 over gdb-11.0.50 May 27th, 2023: GDB 13.2 Released! The latest version of GDB, version 13.2, is available for download. This is a minor corrective release over GDB 13.1, fixing the following issues: PR testsuite/30158 (rustc testsuite fails with 13.1, apparently worked before with trunk 20230114 on i686-linux-gnu and powerpc64le-linux-gnu) PR gdb/30214 (GDB 13.1 does not compile on FreeBSD 13.1) PR gdb/30240 ((linux/aarch) thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed) PR gdb/30249 ([13 regression] hookpost-extended-remote will not work) PR exp/30271 (Addresses of static thread_local fields are badly calculated sometimes) PR symtab/30357 (Segmentation fault for the 'start' command) PR symtab/30369 ([gdb/symtab] False match issue in skip_prologue_using_linetable) PR gdb/30423 (Build failures with clang 16) PR build/30450 (Build failure (linux-low.cc:5393:45: error: expected ':' before ')' token) with musl-1.2.4) See the NEWS file for a more complete and detailed list of what this release includes. Feb 19th, 2023: GDB 13.1 Released! The latest version of GDB, version 13.1, is available for download. This version of GDB includes the following changes and enhancements: Support for the following new targets has been added in both GDB and GDBserver: GNU/Linux/LoongArch (gdbserver) loongarch*-*-linux* GNU/Linux/CSKY (gdbserver) csky*-*linux* The Windows native target now supports target async. FreeBSD: Arm and AArch64: Support for Thread Local Storage (TLS) variables Hardware watchpoint support on AArch64 FreeBSD Floating-point support has now been added on LoongArch GNU/Linux. New commands: set print nibbles [on|off] show print nibbles This controls whether the 'print/t' command will display binary values in groups of four bits, known as "nibbles". The default is 'off'. Various styling-related commands. See the gdb/NEWS file for more details. Various maintenance commands. These are normally aimed at GDB experts or developers. See the gdb/NEWS file for more details. Python API improvements: New Python API for instruction disassembly. The new attribute 'locations' of gdb.Breakpoint returns a list of gdb.BreakpointLocation objects specifying the locations where the breakpoint is inserted into the debuggee. New Python type gdb.BreakpointLocation. New function gdb.format_address(ADDRESS, PROGSPACE, ARCHITECTURE) that formats ADDRESS as 'address ' New function gdb.current_language that returns the name of the current language. Unlike gdb.parameter('language'), this will never return 'auto'. New function gdb.print_options that returns a dictionary of the prevailing print options, in the form accepted by gdb.Value.format_string. New method gdb.Frame.language that returns the name of the frame's language. gdb.Value.format_string now uses the format provided by 'print', if it is called during a 'print' or other similar operation. gdb.Value.format_string now accepts the 'summary' keyword. This can be used to request a shorter representation of a value, the way that 'set print frame-arguments scalars' does. The gdb.register_window_type method now restricts the set of acceptable window names. The first character of a window's name must start with a character in the set [a-zA-Z], every subsequent character of a window's name must be in the set [-_.a-zA-Z0-9]. ` GDB/MI changes: MI version 1 is deprecated, and will be removed in GDB 14. The async record stating the stopped reason 'breakpoint-hit' now contains an optional field locno. Miscellaneous improvements: gdb now supports zstd compressed debug sections (ELFCOMPRESS_ZSTD) for ELF. New convenience variable $_inferior_thread_count contains the number of live threads in the current inferior. New convenience variables $_hit_bpnum and $_hit_locno, set to the breakpoint number and the breakpoint location number of the breakpoint last hit. The "info breakpoints" now displays enabled breakpoint locations of disabled breakpoints as in the "y-" state. The format of 'disassemble /r' and 'record instruction-history /r' has changed to match the layout of GNU objdump when disassembling. A new format "/b" has been introduce to provide the old behavior of "/r". The TUI no longer styles the source and assembly code highlighted by the current position indicator by default. You can however re-enable styling using the new "set style tui-current-position" command. It is now possible to use the "document" command to document user-defined commands. Support for memory tag data for AArch64 MTE. Support Removal notices: DBX mode has been removed. Support for building against Python version 2 has been removed. It is now only possible to build GDB against Python 3. Support for the following commands has been removed: set debug aix-solib on|off show debug aix-solib set debug solib-frv on|off show debug solib-frv Use the "set/show debug solib" commands instead. See the NEWS file for a more complete and detailed list of what this release includes. Dec 18th, 2022: GDB 13 branch created The GDB 13 branch (gdb-13-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-13-branch https://sourceware.org/git/binutils-gdb.git May 1st, 2022: GDB 12.1 Released! The latest version of GDB, version 12.1, is available for download. This version of GDB includes the following changes and enhancements: New support for the following native configuration: GNU/Linux/OpenRISC or1k*-*-linux* New support for the following targets: GNU/Linux/LoongArch loongarch*-*-linux* New GDBserver support on the following configuration: GNU/Linux/OpenRISC or1k*-*-linux* Support for the following target has been removed: S+core score-*-* Multithreaded symbol loading is now enabled by default Deprecation Notices: GDB 12 is the last release of GDB that will support building against Python 2 DBX mode is deprecated, and will be removed in GDB 13 GDB/MI changes: The '-add-inferior' with no option flags now inherits the connection of the current inferior, this restores the behaviour of GDB as it was prior to GDB 10. The '-add-inferior' command now accepts a '--no-connection' option, which causes the new inferior to start without a connection. Python API enhancements: It is now possible to add GDB/MI commands implemented in Python New function gdb.Architecture.integer_type() New gdb.events.gdb_exiting event New 'gdb.events.connection_removed' event registry New gdb.TargetConnection object New gdb.Inferior.connection property New read-only attribute gdb.InferiorThread.details New gdb.RemoteTargetConnection.send_packet method New read-only attributes gdb.Type.is_scalar and gdb.Type.is_signed The gdb.Value.format_string method now takes a 'styling' argument Various new function in the "gdb" module Miscellaneous: The FreeBSD native target now supports async mode Improved C++ template support Support for disabling source highlighting through GNU of the Pygments library instead. The "print" command has been changed so as to print floating-point values with a base-modifying formats such as "/x" to display the underlying bytes of the value in the desired base. The "clone-inferior" command now ensures that the TTY, CMD and ARGS settings are copied from the original inferior to the new one. All modifications to the environment variables done using the 'set environment' or 'unset environment' commands are also copied to the new inferior. Various new commands have been introduced See the NEWS file for a more complete and detailed list of what this release includes. Mar 20th, 2022: GDB 12 branch created The GDB 12 branch (gdb-12-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-12-branch https://sourceware.org/git/binutils-gdb.git January 16th, 2022: GDB 11.2 Released! The latest version of GDB, version 11.2, is available for download. This is a minor corrective release over GDB 11.1, fixing the following issues: PR sim/28302 (gdb fails to build with glibc 2.34) PR build/28318 (std::thread support configure check does not use CXX_DIALECT) PR gdb/28405 (arm-none-eabi: internal-error: ptid_t remote_target::select_thread_for_ambiguous_stop_reply(const target_waitstatus*): Assertion `first_resumed_thread != nullptr' failed) PR tui/28483 ([gdb/tui] breakpoint creation not displayed) PR build/28555 (uclibc compile failure since commit 4655f8509fd44e6efabefa373650d9982ff37fd6) PR rust/28637 (Rust characters will be encoded using DW_ATE_UTF) PR gdb/28758 (GDB 11 doesn't work correctly on binaries with a SHT_RELR (.relr.dyn) section) PR gdb/28785 (Support SHT_RELR (.relr.dyn) section) See the NEWS file for a more complete and detailed list of what this release includes. September 13th, 2021: GDB 11.1 Released! The latest version of GDB, version 11.1, is available for download. This version of GDB includes the following changes and enhancements: Support for ARM Symbian (arm*-*-symbianelf*) has been removed. Building GDB now requires GMP (The GNU Multiple Precision Arithmetic Library). New command-line options "--early-init-command" (or "-eix") and "--early-init-eval-command" (or "-eiex") GDB/MI Changes: New --qualified option for the '-break-insert' and '-dprintf-insert' commands. New --force-condition option for the '-break-insert' and '-dprintf-insert' commands. New --force option for the '-break-condition' command. The '-file-list-exec-source-files' now accepts an optional regular expression to filter the source files included in the result. The results from '-file-list-exec-source-files' now include a 'debug-fully-read' field to indicate if the corresponding source's debugging information has been partially read (false) or has been fully read (true). TUI Improvements: Mouse actions are now supported. The mouse wheel scrolls the appropriate window. Key combinations that do not have a specific action on the focused window are now passed to GDB. Python enhancements: Inferior objects now contain a read-only 'connection_num' attribute that gives the connection number as seen in 'info connections' and 'info inferiors'. New method gdb.Frame.level() which returns the stack level of the frame object. New method gdb.PendingFrame.level() which returns the stack level of the frame object. When hitting a catchpoint, the Python API will now emit a gdb.BreakpointEvent rather than a gdb.StopEvent. The gdb.Breakpoint attached to the event will have type BP_CATCHPOINT. Python TUI windows can now receive mouse click events. If the Window object implements the click method, it is called for each mouse click event in this window. New setting "python ignore-environment on|off"; if "on", causes GDB's builtin Python to ignore any environment variable that would otherwise affect how Python behaves (needs to be set during "early initialization" (see above). New setting "python dont-write-bytecode auto|on|off". Guile API enhancements: Improved support for rvalue reference values. New procedures for obtaining value variants: value-reference-value, value-rvalue-reference-value and value-const-value. New "qMemTags" and "QMemTags" remote protocol packets (associated with Memory Tagging). GDB will now look for the .gdbinit file in a config directory before looking for ~/.gdbinit. The file is searched for in the following locations: $XDG_CONFIG_HOME/gdb/gdbinit, $HOME/.config/gdb/gdbinit, $HOME/.gdbinit. On Apple hosts the search order is instead: $HOME/Library/Preferences/gdb/gdbinit, $HOME/.gdbinit. The "break [...] if CONDITION" command no longer returns an error when the condition is invalid at one or more locations. Instead, if the condition is valid at one or more locations, the locations where the condition is not valid are disabled. The behavior of the "condition" command is changed to match the new behavior of the "break" command. Support for general memory tagging functionality (currently limited to AArch64 MTE) Core file debugging now supported for x86_64 Cygwin programs. New "org.gnu.gdb.riscv.vector" feature for RISC-V targets. GDB now supports fixed point types which are described in DWARF as base types with a fixed-point encoding. Additionally, support for the DW_AT_GNU_numerator and DW_AT_GNU_denominator has also been added. Miscellaneous: New "startup-quietly on|off" setting; when "on", behaves the same as passing the "-silent" option on the command line. New "print type hex on|off" setting; when 'on', the 'ptype' command uses hexadecimal notation to print sizes and offsets of struct members. When 'off', decimal notation is used. The "inferior" command, when run without argument, prints information about the current inferior. The "ptype" command now supports "/x" and "/d", affecting the base used to print sizes and offsets. The output of the "info source" has been restructured. New "style version foreground | background | intensity" commands to control the styling of the GDB version number. Various debug and maintenance commands (mostly useful for the GDB developers) See the NEWS file for a more complete and detailed list of what this release includes. @ text @d2 1 a2 1 @@c Copyright (C) 1988-2022 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2022 Free Software Foundation, Inc. @ 1.1.1.8.2.1 log @Sync with HEAD @ text @d2 1 a2 1 @@c Copyright (C) 1988-2024 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2024 Free Software Foundation, Inc. d349 4 d500 7 a506 6 Free any target specific information associated with the BFD that isn't freed by @@samp{_bfd_free_cached_info}. This is called when any BFD is closed (the @@samp{bfd_write_contents} function mentioned earlier is only called for a BFD opened for writing). This function pointer is typically set to @@samp{_bfd_generic_close_and_cleanup}, which simply returns true. d509 7 a515 11 This function is designed for use by the generic archive routines, and is also called by bfd_close. After creating the archive map archive element bfds don't need symbols and other structures. Many targets use @@samp{bfd_alloc} to allocate target specific information and thus do not need to do anything special for this entry point, and just set it to @@samp{_bfd_generic_free_cached_info} which throws away objalloc memory for the bfd. Note that this means the bfd tdata and sections are no longer available. Targets that malloc memory, attaching it to the bfd tdata or to section used_by_bfd should implement a target version of this function to free that memory before calling @@samp{_bfd_generic_free_cached_info}. d527 1 a527 1 based on the section's @@samp{filepos} field and a @@samp{bfd_read}. The d531 9 d660 1 a660 1 Write out the archive symbol table using calls to @@samp{bfd_write}. @ 1.1.1.9 log @Import gdb-15.1, previous was 13.2 ChangeLog: 2024-03-20 Simon Marchi * .pre-commit-config.yaml: Bump black hook to 24.3.0 2024-03-20 Simon Marchi * .pre-commit-config.yaml: New. 2024-03-14 Simon Marchi * Makefile.def: Add configure-gdbserver and all-gdbserver dependencies on all-libiconv. * Makefile.in: Re-generate. 2024-01-15 Nick Clifton * 2.42 branch point. 2023-11-15 Arsen Arsenović * intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. : Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory. 2023-07-03 Nick Clifton 2.41 Branch Point. 2023-06-26 Nick Clifton * Import these updates to the config scripts commit 4ad4bb7c30aca1e705448ba8d51a210bbd47bb52 Author: Paul Eggert Date: Fri Jun 23 09:55:10 2023 -0700 Quote 'like this', not `like this'. commit 63acb96f92473ceb5e21d873d7c0aee266b3d6d3 Author: Paul Eggert Date: Sat Jan 21 00:15:01 2023 -0600 Fix config.sub spelling typo for "athlon" commit 4ce12a5c9125cedc0d0ba584444a6865396923ec Author: Dmitry V. Levin Date: Sun Jan 1 08:00:00 2023 +0000 Update copyright years commit c397e2c040bce50bcdccb131f90115ba7e8bfc19 Author: Arsen Arsenovi Date: Sat Sep 17 23:34:48 2022 +0200 config.sub: add linux-mlibc targets commit 9f9f9b0b13197269848c76e3e057a3ed0680b4bf Author: Arsen Arsenovi Date: Sat Sep 17 23:34:47 2022 +0200 config.guess: support running on Managarm systems commit 87e6687749da7bb2ab158a79fa83721c19ed9246 Author: Arsen Arsenovi Date: Sat Sep 17 23:34:46 2022 +0200 config.sub: add managarm-{mlibc,kernel} targets commit 20403c5701973a4cbd7e0b4bbeb627fcd424a0f1 Author: Xiaotian Wu Date: Mon Aug 1 16:05:29 2022 +0800 Remove loongarchx32 commit 02ba26b218d3d3db6c56e014655faf463cefa983 Author: Alexander von Gluck IV Date: Wed May 25 15:43:13 2022 -0500 config.guess: Update Haiku guesses commit f56a7140386d08a531bcfd444d632b28c61a6329 Author: Bruno Haible Date: Sun May 8 19:08:08 2022 +0200 config.guess (x86_64:Linux:*:*): Detect 32-bit ABI. 2023-04-20 Nick Clifton * SECURITY.txt: New file. * src-release.sh (DEVO_SUPPORT): Add SECURITY.txt. 2022-12-31 Nick Clifton * 2.40 binutils branch created. @ text @d2 1 a2 1 @@c Copyright (C) 1988-2024 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2024 Free Software Foundation, Inc. d349 4 d500 7 a506 6 Free any target specific information associated with the BFD that isn't freed by @@samp{_bfd_free_cached_info}. This is called when any BFD is closed (the @@samp{bfd_write_contents} function mentioned earlier is only called for a BFD opened for writing). This function pointer is typically set to @@samp{_bfd_generic_close_and_cleanup}, which simply returns true. d509 7 a515 11 This function is designed for use by the generic archive routines, and is also called by bfd_close. After creating the archive map archive element bfds don't need symbols and other structures. Many targets use @@samp{bfd_alloc} to allocate target specific information and thus do not need to do anything special for this entry point, and just set it to @@samp{_bfd_generic_free_cached_info} which throws away objalloc memory for the bfd. Note that this means the bfd tdata and sections are no longer available. Targets that malloc memory, attaching it to the bfd tdata or to section used_by_bfd should implement a target version of this function to free that memory before calling @@samp{_bfd_generic_free_cached_info}. d527 1 a527 1 based on the section's @@samp{filepos} field and a @@samp{bfd_read}. The d531 9 d660 1 a660 1 Write out the archive symbol table using calls to @@samp{bfd_write}. @ 1.1.1.10 log @Import gdb-17.1, previous was 16.3 This version of GDB includes the following changes and enhancements: * x86-64 CET shadow stack support * Debugging Linux programs that use AArch64 Guarded Control Stacks * GDB record feature now supports rv64gc architectures * 'info threads' command support for two new options '-stopped' and '-running' to limit the list of displayed threads. * On Linux and FreeBSD, the addresses shown by the 'info sharedlibrary' command are now for the full memory range allocated to the shared library. * Linux checkpoints now work with multiple inferiors * Improved linker namespace support * Warnings and error messages now start with an emoji (warning sign, or cross mark) if supported by the host charset. Configurable. * Built-in support for TLS on Linux as backup when libthread_db is not available. Supported on the x86_64, aarch64, ppc64, s390x, and riscv architectures, when compiled with GLIBC or MUSL. * New command "set riscv numeric-register-names" to display risc-v registers using their numeric names instead of their ABI names. * The Alpha target now supports target descriptions. Python API enhancements: * New class gdb.Color for dealing with colors, and new constant gdb.PARAM_COLOR * New gdb.ParameterPrefix class, to create new 'set/show' command prefixes. * New attribute gdb.Value.is_unavailable, this checks for unavailability like gdb.Value.is_optimized_out checks for optimized out values. * New gdb.warning() function to print a warning message, with GDB's standard 'warning' prefix (see emoji support entry below) * gdb.execute has an additional 'styling' argument. * Prefix commands (gdb.Command sub-classes) that don't have an invoke method now behave like builtin prefix commands when invoked without a sub-command name. * Setting the documentation string (__doc__) of a gdb.Parameter sub-class to the empty string, means GDB will only display the set_doc or show_doc strings in the set/show help output. Guile API enhancements: * New type for dealing with colors and constant PARAM_COLOR * Prefix commands (using make-command) that don't have a #:invoke property will now behave like builtin prefix commands when invoked without a sub-command name. * Eliding the #:doc string from make-parameter now means that GDB will use a default documentation string. * Setting #:doc to the empty string for make-parameter means GDB will only display the #:set_doc or #:show_doc strings in the set/show help output. Debugger Adapter Protocol changes: * GDB now supports the "completions" request. * New "--binary-output" command line option to disable LF translations (Windows only) New convenience variables: * $_colorsupport providing a comma-separated list of color space names supported by the terminal. * $linker_namespace_count and $_linker_namespace provide the list of active linker namespaces. Remote package additions and changes: * New 'binary-upload+' value in qSupported reply * The 'vFile:stat' command implementation has been corrected to use stat rather than lstat. * New vFile:lstat packet, useful for handling symbolic links * Support for the "id_str" attribute in 'qXfer:threads:read' XML answer. GDB/MI changes: * The =library-unloaded event now includes the 'ranges' field and the 'still-in-use' field. Configure changes: * Ability to select which file formats to include support for * New option --disable-gdb-compile to disable support for the compile subsystem. * New option --disable-gdb-dwarf-support to disable support for DWARF debug information in GDB. * New option --disable-gdb-mdebug-support to disable support for mdebug/ecoff debug information. Incompatible changes: * Support for Python versions older than 3.4 has been removed * Support for stabs debugging format and the a.out/dbx object format is deprecated, and will be removed in GDB 18. * UST (static tracepoint) gdbserver support has been removed @ text @d2 1 a2 1 @@c Copyright (C) 1988-2025 Free Software Foundation, Inc. d17 1 a17 1 Copyright @@copyright{} 1988-2025 Free Software Foundation, Inc. @