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, 30 Dec 2009, Pedro Alves wrote:
> On Wednesday 30 December 2009 19:38:29, Vincent Torri wrote:
>>
>> On Wed, 30 Dec 2009, Pedro Alves wrote:
>>
>>> On Tuesday 29 December 2009 06:33:30, Vincent Torri wrote:
>>>
about the linking, should I pass -Wl,--major-subsystem-version,4 and
>>>
On Wednesday 30 December 2009 19:38:29, Vincent Torri wrote:
>
> On Wed, 30 Dec 2009, Pedro Alves wrote:
>
> > On Tuesday 29 December 2009 06:33:30, Vincent Torri wrote:
> >
> >> about the linking, should I pass -Wl,--major-subsystem-version,4 and
> >> -Wl,--minor-subsystem-version,20 ?
> >
> > I
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, 30 Dec 2009, Pedro Alves wrote:
> On Tuesday 29 December 2009 06:33:30, Vincent Torri wrote:
>
>> about the linking, should I pass -Wl,--major-subsystem-version,4 and
>> -Wl,--minor-subsystem-version,20 ?
>
> I can't remember if this has any effect on dlls (IIRC, application
> user inter
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 Tuesday 29 December 2009 06:33:30, Vincent Torri wrote:
> about the linking, should I pass -Wl,--major-subsystem-version,4 and
> -Wl,--minor-subsystem-version,20 ?
I can't remember if this has any effect on dlls (IIRC, application
user interface look different [menubar, etc.] if you specify a
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
Hi,
We found that in limits.h UCHAR_MAX is not defined, can someone have a look
at this?
Johnny
http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
http://msdn.microsoft.com/en-us/library/296az74e%28VS.71%29.aspx
16 matches
Mail list logo
