I see what's going on.
First off, notice that __image_base__ is placed in the
absolute section:
>arm-mingw32ce-nm -A lib7.dll | grep image_base
lib7.dll:00010000 A __image_base__
while __RUNTIME_PSEUDO_RELOC_LIST__ is placed in .rdata
>arm-mingw32ce-nm -A lib7.dll | grep __RUNTIME_PSEUDO_RELOC_LIST__
lib7.dll:00022000 R __RUNTIME_PSEUDO_RELOC_LIST__
>arm-mingw32ce-objdump -h lib7.dll
lib7.dll: file format pei-arm-wince-little
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000068 00011000 00011000 00000400 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00010000 00012000 00012000 00000600 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 00000054 00022000 00022000 00010600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .reloc 0000000c 00023000 00023000 00010800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
That's expected as well.
Now, why would a relocation against a symbol at 0x0010000 (image base)
fail, and against 00022000 (__RUNTIME_PSEUDO_RELOC_LIST__) succeed?
My hunch is that the issue is that 0x0010000 is not an ALLOC|LOAD
address. It is _not_ part of the image at runtime.
To make it easier to confirm the hunch, I've done a small tweak
to the test file. I'm referencing my own symbol, called
__my_image_base__, like so:
#include <windows.h>
BOOL WINAPI
DllMainCRTStartup (HANDLE h, DWORD reason, LPVOID lpReserved)
{
return TRUE;
}
static char big_buf[0x010000] = { '1' };
extern DWORD __U(__RUNTIME_PSEUDO_RELOC_LIST__);
extern DWORD __U(_image_base__);
extern DWORD __U(_my_image_base__);
__declspec (dllexport)
int doit (void)
{
void *p;
p = &__U(_my_image_base__);
// p = &__size_of_heap_commit__;
// p = &__U(_image_base__);
// p = &__U(__RUNTIME_PSEUDO_RELOC_LIST__);
// p = DllMainCRTStartup;
return (int)p;
}
And, I'm using ld's --defsym switch to define it.
A dll linked like this fails to load:
>arm-mingw32ce-gcc -c lib7.c && arm-mingw32ce-ld --shared -Bdynamic -e
>DllMainCRTStartup -o lib7.dll lib7.o -lcoredll --defsym
>__my_image_base__=0x10ffc
>arm-mingw32ce-nm -A lib7.dll | grep my_image_base
lib7.dll:00010ffc A __my_image_base__
And linked like this loads correctly:
>arm-mingw32ce-gcc -c lib7.c && arm-mingw32ce-ld --shared -Bdynamic -e
>DllMainCRTStartup -o lib7.dll lib7.o -lcoredll --defsym
>__my_image_base__=0x11000
>arm-mingw32ce-nm -A lib7.dll | grep my_image_base
lib7.dll:00011000 A __my_image_base__
Furthermore, this succeeds:
>arm-mingw32ce-gcc -c lib7.c && arm-mingw32ce-ld --shared -Bdynamic -e
>DllMainCRTStartup -o lib7.dll lib7.o -lcoredll --defsym
>__my_image_base__=0x23000
And this fails:
>arm-mingw32ce-gcc -c lib7.c && arm-mingw32ce-ld --shared -Bdynamic -e
>DllMainCRTStartup -o lib7.dll lib7.o -lcoredll --defsym
>__my_image_base__=0x2300c
0002300c is the vma of the .reloc section + sizeof the .reloc section, that is,
just over the end of the image.
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.
--
Pedro Alves
------------------------------------------------------------------------------
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
