diff options
| -rw-r--r-- | ld/ChangeLog-2009 | 2 | ||||
| -rw-r--r-- | ld/ChangeLog-9197 | 2 | ||||
| -rw-r--r-- | ld/configure.ac | 4 | ||||
| -rw-r--r-- | ld/configure.host | 6 | ||||
| -rw-r--r-- | ld/ldexp.c | 2 | ||||
| -rw-r--r-- | ld/ldint.texinfo | 92 |
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 @@ -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 |