On Sun, 2010-01-03 at 21:53 +0100, Kai Tietz wrote:
> 2010/1/3 Danny Backx :
> > On Sun, 2010-01-03 at 21:14 +0100, Kai Tietz wrote:
> >> Ah, one point I missed here to describe, why I didn't changed
> >> pe.em/pe.sc here. The reason is, that by using pseudo-relocation
> >> version 1, the IAT table
On Sun, 2010-01-03 at 21:14 +0100, Kai Tietz wrote:
> Yes, I am still listening to this thread ;)
Thanks !
> 2010/1/3 Kai Tietz :
> > Those are the original patches I've sent. (as remark, those patches
> > are just changing pep.em, but the same patch for it has to be added to
> > pe.em, too). Lik
On Sunday 03 January 2010 13:33:57, Vincent R. wrote:
> Originally pseudo-reloc v2 was necessary to fix IAT address because
> until now it was NULL.
In reality, IIUC, the IAT needed fixing as a prerequisite for
pseudo-relocs v2 to work. This (binutils/ld fix) was also required
for WM6.1. It was
On Sunday 03 January 2010 16:32:39, Danny Backx wrote:
> On Sun, 2010-01-03 at 12:11 +, Pedro Alves wrote:
> > On Saturday 02 January 2010 16:42:23, Danny Backx wrote:
> > > On Fri, 2010-01-01 at 16:24 +, Pedro Alves wrote:
> > > > FYI, I hadn't applied the ld patch myself because I was
> >
On Sun, 2010-01-03 at 12:11 +, Pedro Alves wrote:
> On Saturday 02 January 2010 16:42:23, Danny Backx wrote:
> > On Fri, 2010-01-01 at 16:24 +, Pedro Alves wrote:
> > > FYI, I hadn't applied the ld patch myself because I was
> > > looking to confirm/hear if there's another cleaner way
> > >
On Sun, 3 Jan 2010 12:11:10 +, Pedro Alves
wrote:
> On Saturday 02 January 2010 16:42:23, Danny Backx wrote:
>> On Fri, 2010-01-01 at 16:24 +, Pedro Alves wrote:
>> > FYI, I hadn't applied the ld patch myself because I was
>> > looking to confirm/hear if there's another cleaner way
>> > to
On Saturday 02 January 2010 16:42:23, Danny Backx wrote:
> On Fri, 2010-01-01 at 16:24 +, Pedro Alves wrote:
> > FYI, I hadn't applied the ld patch myself because I was
> > looking to confirm/hear if there's another cleaner way
> > to get at the image base, but I can't find one. Anyway, I've
>
On Fri, 2010-01-01 at 16:24 +, Pedro Alves wrote:
> On Friday 01 January 2010 09:37:34, Danny Backx wrote:
> > On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
> > > With the patches pasted below, a dll linked with the full mingw
> > > runtime loaded successfully for me.
> >
> > My tests
On Thursday 31 December 2009 16:11:49, Pedro Alves wrote:
>
> 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.
One thing that would be nice, although low priority, is to tweak ld to
On Friday 01 January 2010 09:37:34, Danny Backx wrote:
> On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
> > With the patches pasted below, a dll linked with the full mingw
> > runtime loaded successfully for me.
>
> My tests confirm this too, I've committed.
FYI, I hadn't applied the ld pa
Hey guys,
I want to congratulate you for finding and fixing this problem. This is a
really beautiful chain of events.
Happy new year! 2010 seems to be a good start for the cegcc project :)
Regards
Sebastien
--
This SF.Ne
On Friday 01 January 2010 09:37:34, Danny Backx wrote:
> Next steps :
> 1 Continue testing
> 2 Start talking to the binutils crowd about how to upstream
> 3 Start talking to the gcc crowd about how to upstream
> 4 Port this to arm-cegcc too
> 5 Sort out the ld crash that Pedro saw
> 6 Do a release
On Friday 01 January 2010 09:55:33, Vincent Torri wrote:
> >> what about newlib ?
> >
> > That's arm-cegcc -> item # 4.
>
> i meant: no push of the win ce code upstreram in newlib ?
It's such a broken ugly mess that I rather keep it here.
Besides, all the CE code is contained in a single directo
On Fri, 1 Jan 2010, Danny Backx wrote:
> On Fri, 2010-01-01 at 10:50 +0100, Vincent Torri wrote:
>>
>> On Fri, 1 Jan 2010, Danny Backx wrote:
>>
>>> On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
With the patches pasted below, a dll linked with the full mingw
runtime loaded succ
On Fri, 2010-01-01 at 10:50 +0100, Vincent Torri wrote:
>
> On Fri, 1 Jan 2010, Danny Backx wrote:
>
> > On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
> >> With the patches pasted below, a dll linked with the full mingw
> >> runtime loaded successfully for me.
> >
> > My tests confirm thi
On Fri, 1 Jan 2010, Danny Backx wrote:
> On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
>> With the patches pasted below, a dll linked with the full mingw
>> runtime loaded successfully for me.
>
> My tests confirm this too, I've committed.
>
> Next steps :
> 1 Continue testing
> 2 Start
On Thu, 2009-12-31 at 19:01 +, Pedro Alves wrote:
> With the patches pasted below, a dll linked with the full mingw
> runtime loaded successfully for me.
My tests confirm this too, I've committed.
Next steps :
1 Continue testing
2 Start talking to the binutils crowd about how to upstream
3 St
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
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
On Wed, 2009-12-30 at 21:05 +0100, Kai Tietz wrote:
> 2009/12/30 Danny Backx :
> > 10014a0: 0100tsteq r0, r0
> >
> > Note that this contains the value of __image_base__ .
> >
> > This means, I think, that Windows is choking on relocating the value of
> > __image_base__ itself.
On Wed, 2009-12-30 at 20:05 +0100, Danny Backx wrote:
> I checked all the relocations : the table vs. the assembler. They all
> appear to make sense. They're usually a couple of words between two
> functions (in the .text segment) that are pointers to something in
> another segment. A string litera
On Wed, 2009-12-30 at 00:44 +0100, Danny Backx wrote:
> On Tue, 2009-12-29 at 18:34 +, Pedro Alves wrote:
> > My knee jerk reaction is: you could try a first step at checking if it's
> > a problem with loader applied relocations, or, if it's a runtime,
> > post loader problem. Replace your deb
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
>> > be compatible with MSFT's tools. */
>> > #undef NT_DLL_IMAGE_BASE
>> >
On Wed, 2009-12-30 at 12:41 +0100, Vincent R. wrote:
> Some remarks, DLLs produced by cegcc have a weird IAT address because
> in Data Directories fields there is :
>
> Virtual Address Size
> 00033198 0040
>
> and this address doesn't even exists.
Can you privately sen
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
> > be compatible with MSFT's tools. */
> > #undef NT_DLL_IMAGE_BASE
> > #define NT_DLL_IMAGE_BASE 0x0001
> > #endif
>
On Wed, 30 Dec 2009 14:05:35 +0100, Danny Backx
wrote:
> On Wed, 2009-12-30 at 12:41 +0100, Vincent R. wrote:
>> Some remarks, DLLs produced by cegcc have a weird IAT address because
>> in Data Directories fields there is :
>>
>> Virtual Address Size
>> 00033198 0040
>>
On Wed, 2009-12-30 at 12:48 +0100, Sébastien Lorquet wrote:
> would that be related to the SizeOfImage <= 1 limit ? :-)
No. SizeOfImage is a sum of the sizes of sections. ImageBase is just an
assumption (by the development tools) of where the code might actually
run. If the OS can use the assu
On Wed, 2009-12-30 at 12:41 +0100, Vincent R. wrote:
> Some remarks, DLLs produced by cegcc have a weird IAT address because
> in Data Directories fields there is :
>
> Virtual Address Size
> 00033198 0040
>
> and this address doesn't even exists.
>
>
> On a dll produ
would that be related to the SizeOfImage <= 1 limit ? :-)
seb
> Some remarks, DLLs produced by cegcc have a weird IAT address because
> in Data Directories fields there is :
>
> Virtual Address Size
> 00033198 0040
>
> and this address doesn't even exists.
>
>
> On
On Wed, 30 Dec 2009 00:44:08 +0100, Danny Backx
wrote:
> On Tue, 2009-12-29 at 18:34 +, Pedro Alves wrote:
>> My knee jerk reaction is: you could try a first step at checking if
it's
>> a problem with loader applied relocations, or, if it's a runtime,
>> post loader problem. Replace your debu
On Tue, 2009-12-29 at 18:34 +, Pedro Alves wrote:
> My knee jerk reaction is: you could try a first step at checking if it's
> a problem with loader applied relocations, or, if it's a runtime,
> post loader problem. Replace your debug '#if 0' by, say,
>
> at global scope:
> volatile int print
On Tuesday 29 December 2009 18:53:10, Kai Tietz wrote:
> Hello,
>
> 2009/12/29 Pedro Alves :
> > My knee jerk reaction is: you could try a first step at checking if it's
> > a problem with loader applied relocations, or, if it's a runtime,
> > post loader problem. Replace your debug '#if 0' by, s
My knee jerk reaction is: you could try a first step at checking if it's
a problem with loader applied relocations, or, if it's a runtime,
post loader problem. Replace your debug '#if 0' by, say,
at global scope:
volatile int print_base = 0;
{
...
if (print_base)
wsprintf(msg, L"Ptr %p", &
On Tue, 2009-12-29 at 16:28 +, Pedro Alves wrote:
> On Tuesday 29 December 2009 14:49:36, Danny Backx wrote:
> > Replacing the underlying function do_pseudo_reloc() by an empty one also
> > got the DLL to load. Adding MessageBoxW() calls to print the arguments
> > succeeds, until I try to print
On Tue, 29 Dec 2009 15:49:36 +0100, Danny Backx
wrote:
> On Mon, 2009-12-28 at 10:00 +0100, Danny Backx wrote:
>> I just committed a cleaned up version of my current work.
>>
>> This now has .edata and .idata sections hidden in .rdata, and can
>> generate working DLL and EXEs but with the SizeOfI
On Tuesday 29 December 2009 14:49:36, Danny Backx wrote:
> On Mon, 2009-12-28 at 10:00 +0100, Danny Backx wrote:
> > I just committed a cleaned up version of my current work.
> >
> > This now has .edata and .idata sections hidden in .rdata, and can
> > generate working DLL and EXEs but with the Si
On Mon, 2009-12-28 at 10:00 +0100, Danny Backx wrote:
> I just committed a cleaned up version of my current work.
>
> This now has .edata and .idata sections hidden in .rdata, and can
> generate working DLL and EXEs but with the SizeOfImage <= 1 limit.
>
> Danny
I found one more issue,
54 matches
Mail list logo
