On Thursday 31 December 2009 19:33:35, Pedro Alves wrote:
>
> > Yes you are right I think I was using some custom binutils but now I
> > understand what you meant
> > I suppose its better to declare it as 0x1000 because this is what MS
> > linker uses now.
> >
> >
>
> Yes, I think you're ri
On Wednesday 30 December 2009 16:28:57, Vincent R. wrote:
> On Wed, 30 Dec 2009 15:16:11 +, Pedro Alves
> wrote:
> > On Wednesday 30 December 2009 14:56:18, Vincent R. wrote:
> >>
> >> > #if defined(TARGET_IS_arm_wince_pe)
> >> > /* Windows CE ignores the image base, but we want to
> >> >
On Thursday 31 December 2009 18:52:06, Vincent R. wrote:
>
> > 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
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 +, Pedro Alves wrote:
> > > And, I'm using l
On Thu, 31 Dec 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 +, 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
>
On Thursday 31 December 2009 17:32:02, Danny Backx wrote:
> On Thu, 2009-12-31 at 16:11 +, 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 differe
Something I almost forgot. I noticed something's wrong with ld, when I build
the WM6.1 testcase:
#include
BOOL WINAPI
DllMainCRTStartup (HANDLE h, DWORD reason, LPVOID lpReserved)
{
return TRUE;
}
static char big_buf[0x01] = { '1' };
extern DWORD __U(__RUNTIME_PSEUDO_RELOC_LIST__);
On Thu, 2009-12-31 at 18:32 +0100, Vincent R. wrote:
> On Thu, 31 Dec 2009 18:24:21 +0100, Danny Backx
> wrote:
> > On Thu, 2009-12-31 at 16:33 +, Pedro Alves wrote:
> >> Also, lest I forget, I've just applied this binutils patch to
> >> fix bogus import table sizes. Danny, you had it right i
On Thu, 31 Dec 2009 18:24:21 +0100, Danny Backx
wrote:
> On Thu, 2009-12-31 at 16:33 +, Pedro Alves wrote:
>> Also, lest I forget, I've just applied this binutils patch to
>> fix bogus import table sizes. Danny, you had it right in the
>> export table size, looks like you just forgot to propa
On Thu, 2009-12-31 at 16:11 +, 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
On Thu, 2009-12-31 at 16:33 +, Pedro Alves wrote:
> Also, lest I forget, I've just applied this binutils patch to
> fix bogus import table sizes. Danny, you had it right in the
> export table size, looks like you just forgot to propagate
> the fix.
Thanks.
Danny
--
Danny Backx ; dan
Also, lest I forget, I've just applied this binutils patch to
fix bogus import table sizes. Danny, you had it right in the
export table size, looks like you just forgot to propagate
the fix.
--
Pedro Alves
2009-12-31 Pedro Alves
bfd/
peXXigen.c (_bfd_XXi_final_link_postscript
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:0001 A __image_base__
while __RUNTIME_PSEUDO_RELOC_LIST__ is placed in .rdata
>arm-mingw32ce-nm -A lib7.dll | grep __RUNTIME_PSEUDO_REL
On Thu, 2009-12-31 at 15:14 +0100, Kai Tietz wrote:
> 2009/12/31 Danny Backx :
> > On Thu, 2009-12-31 at 14:30 +0100, Kai Tietz wrote:
> >> Could you try for the __image_base__ symbol the following hack. Maybe
> >> it is related to an issue in doing base relocation here in instruction
> >> (which c
On Thu, 2009-12-31 at 14:30 +0100, Kai Tietz wrote:
> Could you try for the __image_base__ symbol the following hack. Maybe
> it is related to an issue in doing base relocation here in instruction
> (which could point to some other issue in object relaxing).
>
> add the following:
> static volatil
>
> Using it instead of the other symbol in my test gives no change.
>
> Oh well, it was worth a try :-(
>
you read my mind :)
It had to be tried!
--
This SF.Net email is sponsored by the Verizon Developer Community
Take a
On Thu, 2009-12-31 at 12:53 +0100, Sébastien Lorquet wrote:
> For the sake of my curiosity, in lib7b.objdump, what's the difference
> between these two symbols?
>
> [ 16](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0100 __ImageBase
> and
>
>
> [ 34](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
On Thu, 2009-12-31 at 13:08 +0100, Vincent R. wrote:
> About your binutils modifications, are they commited ?If I get cegcc
> sources will I be able
> to reproduce what you are experimenting ?
Public reply because others may want to know this too.
Everything is in SVN except a one line change to
For the sake of my curiosity, in lib7b.objdump, what's the difference
between these two symbols?
[ 16](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0100 __ImageBase
and
[ 34](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0100 __image_base__
On Thu, Dec 31, 2009 at 12:05 PM, Danny Backx wr
I've narrowed the demo DLL down to the minimal source I can trigger the
problem with. Doesn't need to compile with any of the runtime modules,
so the compile boils down to :
arm-mingw32ce-gcc -c lib7.c
arm-mingw32ce-ld --shared -Bdynamic -e DllMainCRTStartup -o lib7.dll
lib7.o -lcoredll
Note all
20 matches
Mail list logo
