This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH,i386][4.3][RFC] PIC Generation on windows/cygwin



> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org 
> [mailto:gcc-patches-owner@gcc.gnu.org] On Behalf Of Murali Vemulapati
> Sent: Sunday, 28 January 2007 12:20 p.m.
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH,i386][4.3][RFC] PIC Generation on windows/cygwin
> 
> The GNU linker always links a DLL with a default base address 
> of 0x10000000
> but at most one DLL can be loaded at this address. The common 
> practice on
> windows is to use the rebase.exe utility which takes a list 
> of DLLs that
> a program is going to load and assigns a unique base address 
> for each DLL
> so that they do not overlap when loaded.

This is certainly not a "common" practice on mingw.  More common is the
practice of 
using 

  --enable-auto-image-base           Automatically choose image base for
DLLs
                                       unless user specifies one

to select an image base that is unlikely to cause a load conflict. 
The rebase utility was/is more commonly used on cygwin, since
cygwin1.dll is not relocateable


 But using rebase could be
> cumbersome when the same DLL is linked into different 
> executables because
> we need to ensure it is loaded at the same address in each executable.

Are you referring to something like cygwin1.dll above?  That is an
exceptional case. 

> This issue will become more complex in the case of DLLs loaded at
> runtime using LoadLibrary() interface as by the time LoadLibrary() is
> called, the program would already be running and would have 
> made memory
> allocations making it more difficult to honor the preferred 
> base address.
>

 
> Gcc produces position dependent code in
> the following scenarios:
> 
> 1. references to static data symbols
> 2. references to dllimported function and data symbols
> 3. references to global function and data symbols
> 4. For certain switch statements, gcc generates a jump table of labels
> as opposed to a table of relative offsets.
> 
> This patch fixes this issue by generating true position 
> independent code
> which can be loaded anywhere in the address space without having to
> rebase it.
> 
> ELF executables have a Global Offset Table (GOT) which is 
> accessed by the
> symbol _GLOBAL_OFFSET_TABLE_. This symbol is also used as a 
> base address
> to compute relative offsets of static data references and 
> labels in a jump
> table. For PECOFF executables, there is no such predefined 
> base symbol.
> So, we generate a unique label in each function which will 
> serve as the
> base label for computing all relative offsets. Just like in 
> ELF case, we
> load the address of the base label into the pic register (in 
> a position
> independent way) and convert references to global symbols as 
> displacements
> from the pic register.
> 
> Here is a list of different kinds of global
> symbol references and how they are referenced in PIC mode.
> 
> 1. A static data variable is referenced as a displacement from the
> PIC base label.
> 
> 2. A dllimport'ed (thro __declspec(dllimport)) function or data symbol
> is referenced via a load from the Import Address Table (IAT). For each
> dllimport'ed symbol <sym>, there is a slot in IAT which is referenced
> by the symbol __imp_<sym>. The symbol __imp_<sym> will be at a
> known (at link time) fixed displacement from the PIC base label.
> Hence, the symbol __imp_<sym> may be referenced via a
> displacement from the PIC base label:

That sound very useful, particulary in importing C++ vtables and
typeinfo objects 
> 
> 3.For a global (function or data) symbol which is not 
> explicitly imported
> (through __declspec(dllimport)), we do not know at compile 
> time whether
> the global symbol  will be resolved within the same DLL or 
> will be imported
> from another DLL. This will be known only at link time. We 
> assume that such
> a symbol <sym> is dllimport'ed and reference it via a load from IAT.
> At link time, if it turns out that the symbol is defined 
> within the same DLL,
> the linker will have to provide a symbol definition for 
> __imp_<sym> in the
> .data segment and load it with the symbol address for <sym>. For such
> cases, the GNU ld currently gives an error of form:
> (.text+0x115): undefined reference to `__imp__foo'.
> 

Presumeably, the MS, Borland,  and other PECOFF linkers will also have
this problem.
Does this mean that PIC switch will make objects that cannot be used by
native toolchains?
If so we need a warning, at least in the documentation.

Danny


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]