From e4de380ca624a27d8d7890ba067b0f7e91349e1f Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 25 Mar 2008 21:13:49 +0000 Subject: [PATCH] * README: Rewrite, with some notes on unsupported features. --- gold/README | 55 +++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 45 insertions(+), 10 deletions(-) diff --git a/gold/README b/gold/README index aa318f2daa..49de60ad87 100644 --- a/gold/README +++ b/gold/README @@ -1,18 +1,53 @@ gold is an ELF linker. It is intended to have complete support for -ELF and to run as fast as possible on modern systems. +ELF and to run as fast as possible on modern systems. For normal use +it is a drop-in replacement for the older GNU linker. -It is written in C++. It is (intended to be) a GNU program, and -therefore follows the GNU formatting standards as modified for C++. -Source documents in order of precedence: +gold is part of the GNU binutils. See ../binutils/README for more +general notes, including where to send bug reports. + +gold was originally developed at Google, and was contributed to the +Free Software Foundation in March 2008. At Google it was designed by +Ian Lance Taylor, with major contributions by Cary Coutant, Craig +Silverstein, and Andrew Chatham. + +The existing GNU linker manual is intended to be accurate +documentation for features which gold supports. gold supports most of +the features of the GNU linker for ELF targets. Notable +omissions--features of the GNU linker not currently supported in +gold--are: + * MEMORY regions in linker scripts + * MRI compatible linker scripts + * linker map files (-M, -Map) + * cross-reference reports (--cref) + * linker garbage collection (--gc-sections) + * position independent executables (-pie) + * various other minor options + + +Notes on the code +================= + +These are some notes which may be helpful to people working on the +source code of gold itself. + +gold is written in C++. It is a GNU program, and therefore follows +the GNU formatting standards as modified for C++. Source documents in +order of decreasing precedence: http://www.gnu.org/prep/standards/ http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/C++STYLE http://www.zembu.com/eng/procs/c++style.html The linker is intended to have complete support for cross-compilation, -which still supporting the normal case of native linking as fast as -possible. This makes the code more complex. +while still supporting the normal case of native linking as fast as +possible. In order to do this, many classes are actually templates +whose parameter is the ELF file class (e.g., 32 bits or 64 bits). The +C++ code is the same, but we don't pay the execution time cost of +always using 64-bit integers if the target is 32 bits. Many of these +class templates also have an endianness parameter: true for +big-endian, false for little-endian. -Many functions are actually templates whose parameter is the ELF file -class (e.g., 32 bits or 64 bits). The code is the same, but we don't -want to pay the execution time cost of always using 64-bit integers if -the target is 32 bits. +The linker is multi-threaded. The Task class represents a single unit +of work. Task objects are stored on a single Workqueue object. Tasks +communicate via Task_token objects. Task_token objects are only +manipulated while holding the master Workqueue lock. Relatively few +mutexes are used. -- 2.11.0