darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Remove trailing spaces in ld

Browse source
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
Show stats Download patch file Download diff file Expand all files Collapse all files

2
ld/ChangeLog-2009
View file

@ -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.

2
ld/ChangeLog-9197
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}.
* 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

4
ld/configure.ac
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 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/>.

6
ld/configure.host
View file

@ -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

2
ld/ldexp.c
View file

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

92
ld/ldint.texinfo
View file

@ -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