Remove trailing spaces in ld

1 files changed, 46 insertions, 46 deletions

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