Remove trailing spaces in ld

This commit is contained in:
H.J. Lu 2015-08-12 04:46:43 -07:00
parent 43e65147c0
commit 995da1ffa7
6 changed files with 54 additions and 54 deletions

View File

@ -91,7 +91,7 @@
* emultempl/xtensaelf.em: Remove --no-relax option. * emultempl/xtensaelf.em: Remove --no-relax option.
(before_allocation): Test RELAXATION_ENABLED macro. (before_allocation): Test RELAXATION_ENABLED macro.
Use ENABLE_RELAXATION macro. Use ENABLE_RELAXATION macro.
2009-11-25 Kai Tietz <kai.tietz@onevision.com> 2009-11-25 Kai Tietz <kai.tietz@onevision.com>
* scripttempl/pe.sc: (.note.GNU-stack): Mark as discardable. * scripttempl/pe.sc: (.note.GNU-stack): Mark as discardable.

View File

@ -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}. * 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. * Makefile.in: Noted change.
* scripttempl/a29k.sc: Don't include /lab3/u3/..../segments.o; I * scripttempl/a29k.sc: Don't include /lab3/u3/..../segments.o; I

View File

@ -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 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 the Free Software Foundation; either version 3 of the License, or
dnl (at your option) any later version. dnl (at your option) any later version.
dnl dnl
dnl This program is distributed in the hope that it will be useful, 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 but WITHOUT ANY WARRANTY; without even the implied warranty of
dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
dnl GNU General Public License for more details. dnl GNU General Public License for more details.
dnl dnl
dnl You should have received a copy of the GNU General Public License 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 along with this program; see the file COPYING3. If not see
dnl <http://www.gnu.org/licenses/>. dnl <http://www.gnu.org/licenses/>.

View File

@ -9,12 +9,12 @@
# it under the terms of the GNU General Public License as published by # it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or # the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version. # (at your option) any later version.
# #
# This program is distributed in the hope that it will be useful, # This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of # but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details. # GNU General Public License for more details.
# #
# You should have received a copy of the GNU General Public License # You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING3. If not see # along with this program; see the file COPYING3. If not see
# <http://www.gnu.org/licenses/>. # <http://www.gnu.org/licenses/>.
@ -180,7 +180,7 @@ i[3-7]86-*-mingw*)
#We only support msvcrt.dll, crtid == 2. #We only support msvcrt.dll, crtid == 2.
HOSTING_CRT0='/mingw/lib/crt2.o' 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`' 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*) mips*-sgi-irix4* | mips*-sgi-irix5*)
HOSTING_CRT0=/usr/lib/crt1.o HOSTING_CRT0=/usr/lib/crt1.o

View File

@ -877,7 +877,7 @@ fold_name (etree_type *tree)
} }
/* Return true if TREE is '.'. */ /* Return true if TREE is '.'. */
static bfd_boolean static bfd_boolean
is_dot (const etree_type *tree) is_dot (const etree_type *tree)
{ {

View File

@ -596,7 +596,7 @@ In summary,
@chapter Some Architecture Specific Notes @chapter Some Architecture Specific Notes
This is the place for notes on the behavior of @code{ld} on 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). of that, only the auto-import behavior for DLLs).
@menu @menu
@ -608,23 +608,23 @@ of that, only the auto-import behavior for DLLs).
@table @emph @table @emph
@code{ld} can create DLLs that operate with various runtimes available @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. the mingw "platform"), cygwin, and pw.
@item auto-import from DLLs @item auto-import from DLLs
@enumerate @enumerate
@item @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 without any concern from their side (for example, without any source
code modifications). Auto-import can be enabled using the code modifications). Auto-import can be enabled using the
@code{--enable-auto-import} flag, or disabled via the @code{--enable-auto-import} flag, or disabled via the
@code{--disable-auto-import} flag. Auto-import is disabled by default. @code{--disable-auto-import} flag. Auto-import is disabled by default.
@item @item
This is done completely in bounds of the PE specification (to be fair, 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 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. compiler/linker.
@item @item
@ -634,59 +634,59 @@ type may be mixed together.
@item @item
Overhead (space): 8 bytes per imported symbol, plus 20 for each Overhead (space): 8 bytes per imported symbol, plus 20 for each
reference to it; Overhead (load time): negligible; Overhead reference to it; Overhead (load time): negligible; Overhead
(virtual/physical memory): should be less than effect of DLL (virtual/physical memory): should be less than effect of DLL
relocation. relocation.
@end enumerate @end enumerate
Motivation Motivation
The obvious and only way to get rid of dllimport insanity is The obvious and only way to get rid of dllimport insanity is
to make client access variable directly in the DLL, bypassing to make client access variable directly in the DLL, bypassing
the extra dereference imposed by ordinary DLL runtime linking. the extra dereference imposed by ordinary DLL runtime linking.
I.e., whenever client contains something like I.e., whenever client contains something like
@code{mov dll_var,%eax,} @code{mov dll_var,%eax,}
address of dll_var in the command should be relocated to point 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 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 make ld help with that. Import section of PE made following
way: there's a vector of structures each describing imports way: there's a vector of structures each describing imports
from particular DLL. Each such structure points to two other from particular DLL. Each such structure points to two other
parallel vectors: one holding imported names, and one which parallel vectors: one holding imported names, and one which
will hold address of corresponding imported name. So, the will hold address of corresponding imported name. So, the
solution is de-vectorize these structures, making import solution is de-vectorize these structures, making import
locations be sparse and pointing directly into code. locations be sparse and pointing directly into code.
Implementation Implementation
For each reference of data symbol to be imported from DLL (to For each reference of data symbol to be imported from DLL (to
set of which belong symbols with name <sym>, if __imp_<sym> is set of which belong symbols with name <sym>, if __imp_<sym> is
found in implib), the import fixup entry is generated. That found in implib), the import fixup entry is generated. That
entry is of type IMAGE_IMPORT_DESCRIPTOR and stored in .idata$3 entry is of type IMAGE_IMPORT_DESCRIPTOR and stored in .idata$3
subsection. Each fixup entry contains pointer to symbol's address subsection. Each fixup entry contains pointer to symbol's address
within .text section (marked with __fuN_<sym> symbol, where N is within .text section (marked with __fuN_<sym> symbol, where N is
integer), pointer to DLL name (so, DLL name is referenced by integer), pointer to DLL name (so, DLL name is referenced by
multiple entries), and pointer to symbol name thunk. Symbol name multiple entries), and pointer to symbol name thunk. Symbol name
thunk is singleton vector (__nm_th_<symbol>) pointing to thunk is singleton vector (__nm_th_<symbol>) pointing to
IMAGE_IMPORT_BY_NAME structure (__nm_<symbol>) directly containing IMAGE_IMPORT_BY_NAME structure (__nm_<symbol>) directly containing
imported name. Here comes that "om the edge" problem mentioned above: imported name. Here comes that "om the edge" problem mentioned above:
PE specification rambles that name vector (OriginalFirstThunk) should PE specification rambles that name vector (OriginalFirstThunk) should
run in parallel with addresses vector (FirstThunk), i.e. that they run in parallel with addresses vector (FirstThunk), i.e. that they
should have same number of elements and terminated with zero. We violate should have same number of elements and terminated with zero. We violate
this, since FirstThunk points directly into machine code. But in this, since FirstThunk points directly into machine code. But in
practice, OS loader implemented the sane way: it goes thru practice, OS loader implemented the sane way: it goes thru
OriginalFirstThunk and puts addresses to FirstThunk, not something OriginalFirstThunk and puts addresses to FirstThunk, not something
else. It once again should be noted that dll and symbol name else. It once again should be noted that dll and symbol name
structures are reused across fixup entries and should be there structures are reused across fixup entries and should be there
anyway to support standard import stuff, so sustained overhead is anyway to support standard import stuff, so sustained overhead is
20 bytes per reference. Other question is whether having several 20 bytes per reference. Other question is whether having several
IMAGE_IMPORT_DESCRIPTORS for the same DLL is possible. Answer is yes, 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 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 fact resident in windows9x kernel32.dll, so if you use it, you have
two IMAGE_IMPORT_DESCRIPTORS for kernel32.dll). Yet other question is two IMAGE_IMPORT_DESCRIPTORS for kernel32.dll). Yet other question is
whether referencing the same PE structures several times is valid. whether referencing the same PE structures several times is valid.
The answer is why not, prohibiting that (detecting violation) would The answer is why not, prohibiting that (detecting violation) would
require more work on behalf of loader than not doing it. require more work on behalf of loader than not doing it.
@end table @end table