aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorH.J. Lu <hjl.tools@gmail.com>2015-08-12 04:46:43 -0700
committerH.J. Lu <hjl.tools@gmail.com>2015-08-12 04:46:43 -0700
commit995da1ffa716fb748cc6a664e81843e751270b45 (patch)
tree6a4b758b90d7f7c1bb03bbc0772b16c902338aa6
parent43e65147c07b1400ae0dbb6694882eceb2363713 (diff)
downloadfsf-binutils-gdb-995da1ffa716fb748cc6a664e81843e751270b45.zip
fsf-binutils-gdb-995da1ffa716fb748cc6a664e81843e751270b45.tar.gz
fsf-binutils-gdb-995da1ffa716fb748cc6a664e81843e751270b45.tar.bz2
Remove trailing spaces in ld
-rw-r--r--ld/ChangeLog-20092
-rw-r--r--ld/ChangeLog-91972
-rw-r--r--ld/configure.ac4
-rw-r--r--ld/configure.host6
-rw-r--r--ld/ldexp.c2
-rw-r--r--ld/ldint.texinfo92
6 files changed, 54 insertions, 54 deletions
diff --git a/ld/ChangeLog-2009 b/ld/ChangeLog-2009
index 0e4555b..9f78c96 100644
--- a/ld/ChangeLog-2009
+++ b/ld/ChangeLog-2009
@@ -91,7 +91,7 @@
* emultempl/xtensaelf.em: Remove --no-relax option.
(before_allocation): Test RELAXATION_ENABLED macro.
Use ENABLE_RELAXATION macro.
-
+
2009-11-25 Kai Tietz <kai.tietz@onevision.com>
* scripttempl/pe.sc: (.note.GNU-stack): Mark as discardable.
diff --git a/ld/ChangeLog-9197 b/ld/ChangeLog-9197
index ca31620..57c775b 100644
--- a/ld/ChangeLog-9197
+++ b/ld/ChangeLog-9197
@@ -4712,7 +4712,7 @@ Fri May 27 12:25:33 1994 Ken Raeburn (raeburn@cujo.cygnus.com)
* emultempl/generic.em: Find emultempl/stringify.sed in ${srcdir}.
- * testsuite/ld-cdtest/cdtest-bar.cc: Renamed from cdtest-func.cc.
+ * testsuite/ld-cdtest/cdtest-bar.cc: Renamed from cdtest-func.cc.
* Makefile.in: Noted change.
* scripttempl/a29k.sc: Don't include /lab3/u3/..../segments.o; I
diff --git a/ld/configure.ac b/ld/configure.ac
index 62aed09..e1d2c81 100644
--- a/ld/configure.ac
+++ b/ld/configure.ac
@@ -6,12 +6,12 @@ dnl This file is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
dnl the Free Software Foundation; either version 3 of the License, or
dnl (at your option) any later version.
-dnl
+dnl
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
dnl GNU General Public License for more details.
-dnl
+dnl
dnl You should have received a copy of the GNU General Public License
dnl along with this program; see the file COPYING3. If not see
dnl <http://www.gnu.org/licenses/>.
diff --git a/ld/configure.host b/ld/configure.host
index 2045733..83f666c 100644
--- a/ld/configure.host
+++ b/ld/configure.host
@@ -9,12 +9,12 @@
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
-#
+#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-#
+#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING3. If not see
# <http://www.gnu.org/licenses/>.
@@ -180,7 +180,7 @@ i[3-7]86-*-mingw*)
#We only support msvcrt.dll, crtid == 2.
HOSTING_CRT0='/mingw/lib/crt2.o'
HOSTING_LIBS='-L/mingw/lib -lmingw32 -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lmoldname -lmingwex -lmsvcrt `if [ -f ../gcc/libgcc.a ] ; then echo ../gcc/libgcc.a ; else ${CC} -print-libgcc-file-name; fi`'
- ;;
+ ;;
mips*-sgi-irix4* | mips*-sgi-irix5*)
HOSTING_CRT0=/usr/lib/crt1.o
diff --git a/ld/ldexp.c b/ld/ldexp.c
index 642f8d6..1d4da9a 100644
--- a/ld/ldexp.c
+++ b/ld/ldexp.c
@@ -877,7 +877,7 @@ fold_name (etree_type *tree)
}
/* Return true if TREE is '.'. */
-
+
static bfd_boolean
is_dot (const etree_type *tree)
{
diff --git a/ld/ldint.texinfo b/ld/ldint.texinfo
index 8f69e14..c69758a 100644
--- a/ld/ldint.texinfo
+++ b/ld/ldint.texinfo
@@ -596,7 +596,7 @@ In summary,
@chapter Some Architecture Specific Notes
This is the place for notes on the behavior of @code{ld} on
-specific platforms. Currently, only Intel x86 is documented (and
+specific platforms. Currently, only Intel x86 is documented (and
of that, only the auto-import behavior for DLLs).
@menu
@@ -608,23 +608,23 @@ of that, only the auto-import behavior for DLLs).
@table @emph
@code{ld} can create DLLs that operate with various runtimes available
-on a common x86 operating system. These runtimes include native (using
+on a common x86 operating system. These runtimes include native (using
the mingw "platform"), cygwin, and pw.
-@item auto-import from DLLs
+@item auto-import from DLLs
@enumerate
@item
-With this feature on, DLL clients can import variables from DLL
+With this feature on, DLL clients can import variables from DLL
without any concern from their side (for example, without any source
-code modifications). Auto-import can be enabled using the
-@code{--enable-auto-import} flag, or disabled via the
+code modifications). Auto-import can be enabled using the
+@code{--enable-auto-import} flag, or disabled via the
@code{--disable-auto-import} flag. Auto-import is disabled by default.
@item
This is done completely in bounds of the PE specification (to be fair,
-there's a minor violation of the spec at one point, but in practice
+there's a minor violation of the spec at one point, but in practice
auto-import works on all known variants of that common x86 operating
-system) So, the resulting DLL can be used with any other PE
+system) So, the resulting DLL can be used with any other PE
compiler/linker.
@item
@@ -634,59 +634,59 @@ type may be mixed together.
@item
Overhead (space): 8 bytes per imported symbol, plus 20 for each
-reference to it; Overhead (load time): negligible; Overhead
-(virtual/physical memory): should be less than effect of DLL
+reference to it; Overhead (load time): negligible; Overhead
+(virtual/physical memory): should be less than effect of DLL
relocation.
@end enumerate
Motivation
-The obvious and only way to get rid of dllimport insanity is
-to make client access variable directly in the DLL, bypassing
+The obvious and only way to get rid of dllimport insanity is
+to make client access variable directly in the DLL, bypassing
the extra dereference imposed by ordinary DLL runtime linking.
I.e., whenever client contains something like
@code{mov dll_var,%eax,}
-address of dll_var in the command should be relocated to point
-into loaded DLL. The aim is to make OS loader do so, and than
-make ld help with that. Import section of PE made following
-way: there's a vector of structures each describing imports
-from particular DLL. Each such structure points to two other
-parallel vectors: one holding imported names, and one which
-will hold address of corresponding imported name. So, the
-solution is de-vectorize these structures, making import
+address of dll_var in the command should be relocated to point
+into loaded DLL. The aim is to make OS loader do so, and than
+make ld help with that. Import section of PE made following
+way: there's a vector of structures each describing imports
+from particular DLL. Each such structure points to two other
+parallel vectors: one holding imported names, and one which
+will hold address of corresponding imported name. So, the
+solution is de-vectorize these structures, making import
locations be sparse and pointing directly into code.
Implementation
-For each reference of data symbol to be imported from DLL (to
-set of which belong symbols with name <sym>, if __imp_<sym> is
-found in implib), the import fixup entry is generated. That
-entry is of type IMAGE_IMPORT_DESCRIPTOR and stored in .idata$3
-subsection. Each fixup entry contains pointer to symbol's address
-within .text section (marked with __fuN_<sym> symbol, where N is
-integer), pointer to DLL name (so, DLL name is referenced by
-multiple entries), and pointer to symbol name thunk. Symbol name
-thunk is singleton vector (__nm_th_<symbol>) pointing to
-IMAGE_IMPORT_BY_NAME structure (__nm_<symbol>) directly containing
-imported name. Here comes that "om the edge" problem mentioned above:
-PE specification rambles that name vector (OriginalFirstThunk) should
-run in parallel with addresses vector (FirstThunk), i.e. that they
+For each reference of data symbol to be imported from DLL (to
+set of which belong symbols with name <sym>, if __imp_<sym> is
+found in implib), the import fixup entry is generated. That
+entry is of type IMAGE_IMPORT_DESCRIPTOR and stored in .idata$3
+subsection. Each fixup entry contains pointer to symbol's address
+within .text section (marked with __fuN_<sym> symbol, where N is
+integer), pointer to DLL name (so, DLL name is referenced by
+multiple entries), and pointer to symbol name thunk. Symbol name
+thunk is singleton vector (__nm_th_<symbol>) pointing to
+IMAGE_IMPORT_BY_NAME structure (__nm_<symbol>) directly containing
+imported name. Here comes that "om the edge" problem mentioned above:
+PE specification rambles that name vector (OriginalFirstThunk) should
+run in parallel with addresses vector (FirstThunk), i.e. that they
should have same number of elements and terminated with zero. We violate
-this, since FirstThunk points directly into machine code. But in
-practice, OS loader implemented the sane way: it goes thru
-OriginalFirstThunk and puts addresses to FirstThunk, not something
-else. It once again should be noted that dll and symbol name
-structures are reused across fixup entries and should be there
-anyway to support standard import stuff, so sustained overhead is
-20 bytes per reference. Other question is whether having several
-IMAGE_IMPORT_DESCRIPTORS for the same DLL is possible. Answer is yes,
-it is done even by native compiler/linker (libth32's functions are in
-fact resident in windows9x kernel32.dll, so if you use it, you have
-two IMAGE_IMPORT_DESCRIPTORS for kernel32.dll). Yet other question is
-whether referencing the same PE structures several times is valid.
-The answer is why not, prohibiting that (detecting violation) would
+this, since FirstThunk points directly into machine code. But in
+practice, OS loader implemented the sane way: it goes thru
+OriginalFirstThunk and puts addresses to FirstThunk, not something
+else. It once again should be noted that dll and symbol name
+structures are reused across fixup entries and should be there
+anyway to support standard import stuff, so sustained overhead is
+20 bytes per reference. Other question is whether having several
+IMAGE_IMPORT_DESCRIPTORS for the same DLL is possible. Answer is yes,
+it is done even by native compiler/linker (libth32's functions are in
+fact resident in windows9x kernel32.dll, so if you use it, you have
+two IMAGE_IMPORT_DESCRIPTORS for kernel32.dll). Yet other question is
+whether referencing the same PE structures several times is valid.
+The answer is why not, prohibiting that (detecting violation) would
require more work on behalf of loader than not doing it.
@end table