With the patches pasted below, a dll linked with the full mingw
runtime loaded successfully for me.

On Thursday 31 December 2009 18:06:36, Pedro Alves wrote:
> On Thursday 31 December 2009 17:32:02, Danny Backx wrote:
> > On Thu, 2009-12-31 at 16:11 +0000, Pedro Alves wrote:
> > > And, I'm using ld's --defsym switch to define it.
> > 
> > > It looks like Windows Mobile 6.1's loader is darn strict WRT
> > > to base relocations, and we'll have to figure out a different
> > > way to get at the runtime image base.
> > 
> > A variation of what both you and I have tried should do the trick,
> > shouldn't it ?
> > 
> > Based on the values in your example :
> > - we can't pass __image_base__ = 0x010000
> > - but we can pass 0x011000 == &DllMainCRTStartup
> > then all the additional info we need is 0x01000 (BaseOfCode).
> 
> Yes, but this patch instead should be quite upstreamable:
> 
> Index: binutils/ld/scripttempl/pe.sc
> ===================================================================
> --- binutils.orig/ld/scripttempl/pe.sc  2009-12-31 17:50:54.000000000 +0000
> +++ binutils/ld/scripttempl/pe.sc       2009-12-31 17:52:29.000000000 +0000
> @@ -70,6 +70,7 @@ SECTIONS
>    ${RELOCATING+. = ALIGN(__section_alignment__);}
>    .text ${RELOCATING+ __image_base__ + ( __section_alignment__ < 
> ${TARGET_PAGE_SIZE} ? . : __section_alignment__ )} :
>    {
> +    ${RELOCATING+__text_start__ = . ;}
>      ${RELOCATING+ *(.init)}
>      *(.text)
>      ${R_TEXT}
> @@ -85,6 +86,7 @@ SECTIONS
>      ${RELOCATING+ *(.gcc_exc)}
>      ${RELOCATING+PROVIDE (etext = .);}
>      ${RELOCATING+ *(.gcc_except_table)}
> +    ${RELOCATING+__text_end__ = . ;}
>    }
> 
>    /* The Cygwin32 library uses a section to avoid copying certain data
> 
> There are already __data_start__, __data_end__ and 
> __bss_start__, __bss_end__ symbols, only text range is missing.
> 
> For the 0x01000, we could just hardcode it.  In practice, this is
> the usual size of the PE headers.  Can an image have a bigger header
> than that, in practice?  Or are the variable size bits all in
> idata, edata, etc., which end up in allocated section?  I know that
> gdb hardcodes the 0x1000 (src/gdb/windows-nat.c).
> 
> I don't think it is possible on Windows CE to read the
> IMAGE_OPTIONAL_HEADER and friends from DllMainCRTStartup, starting from
> the passed in handle?  We could get at the image base that way, but
> I think that's only possible on non-CE Windows.  Am I wrong?
> 

-- 
Pedro Alves

2009-12-31  Pedro Alves <pedroal...@users.sourceforge.net>

        ld/
        scripttempl/pe.sc: Define __text_start__ and __text_end__.

---
 ld/scripttempl/pe.sc |    2 ++
 1 file changed, 2 insertions(+)

Index: binutils/ld/scripttempl/pe.sc
===================================================================
--- binutils.orig/ld/scripttempl/pe.sc  2009-12-31 17:50:54.000000000 +0000
+++ binutils/ld/scripttempl/pe.sc       2009-12-31 17:52:29.000000000 +0000
@@ -70,6 +70,7 @@ SECTIONS
   ${RELOCATING+. = ALIGN(__section_alignment__);}
   .text ${RELOCATING+ __image_base__ + ( __section_alignment__ < 
${TARGET_PAGE_SIZE} ? . : __section_alignment__ )} : 
   {
+    ${RELOCATING+__text_start__ = . ;}
     ${RELOCATING+ *(.init)}
     *(.text)
     ${R_TEXT}
@@ -85,6 +86,7 @@ SECTIONS
     ${RELOCATING+ *(.gcc_exc)}
     ${RELOCATING+PROVIDE (etext = .);}
     ${RELOCATING+ *(.gcc_except_table)}
+    ${RELOCATING+__text_end__ = . ;}
   }
 
   /* The Cygwin32 library uses a section to avoid copying certain data



===================================================================


2009-12-31  Pedro Alves  <pedroal...@users.sourceforge.net>

        * pseudo-reloc.c (__text_start__): Declare.
        (_pei386_runtime_relocator): On CE, don't reference
        &__image_base__; get at the image base through __text_start__ -
        0x1000 instead.

---
 mingw/pseudo-reloc.c |   35 +++++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

Index: mingw/pseudo-reloc.c
===================================================================
--- mingw.orig/pseudo-reloc.c   2009-12-31 18:52:36.000000000 +0000
+++ mingw/pseudo-reloc.c        2009-12-31 18:57:37.000000000 +0000
@@ -24,7 +24,8 @@
  
  extern char __RUNTIME_PSEUDO_RELOC_LIST__;
  extern char __RUNTIME_PSEUDO_RELOC_LIST_END__;
- extern char __U(_image_base__);
+ extern char __image_base__;
+ extern char __text_start__;
 
 typedef struct {
   DWORD addend;
@@ -165,17 +166,39 @@ do_pseudo_reloc (void * start, void * en
           break;
 #endif
         }
-     }
- }
- 
+    }
+}
+
 void
- _pei386_runtime_relocator ()
+ _pei386_runtime_relocator (void)
 {
   static int was_init = 0;
+#ifdef UNDER_CE
+  static volatile void *___image_base;
+  static volatile int ___pe_header_size;
+#endif
   if (was_init)
     return;
   ++was_init;
+
+#ifndef UNDER_CE
+  image_base = __image_base__;
+#else
+  /* The loader of Windows Mobile 6.1 and above refuses to apply base
+     relocations if the RVA falls out of the image.  __image_base__
+     happens to be one such symbol, as most other ld magic symbols
+     (__dll__, __major_image_version__, etc.  Basically, symbols that
+     end up on the absolute section.  As an alternative to get at the
+     image base, we relocate against the __text_start__ symbol, and
+     subtract the PE header from that.  In practice, this gives up the
+     image base.  We go through volatile global to make sure gcc
+     doesn't fold the 0x1000 subtraction into the relocatable
+     address.  */
+  ___image_base = &__text_start__;
+  ___pe_header_size = 0x1000;
+#endif
+
   do_pseudo_reloc (&__RUNTIME_PSEUDO_RELOC_LIST__,
                   &__RUNTIME_PSEUDO_RELOC_LIST_END__,
-                   &__U(_image_base__));
+                  (char *) ___image_base - ___pe_header_size);
 }

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

Reply via email to