binutils arm/PE issue causing failure on Windows Mobile 6.1+

binutils arm/PE issue causing failure on Windows Mobile 6.1+

[Danny Backx]

Hi,

I'm forwarding w.r.t. an issue with cegcc (creating WinCE executables
for ARM).

We've had several reports over the last year, which were eventually
tracked down to issues with the PE format exes we create.

See some information about that below. Is the analysis by Vincent - that
some stuff is still missing from binutils - correct ?

Why is that, is there a way in which we can move forward ?

Thanks,

	Danny

On Sat, 2009-09-05 at 12:04 +0200, Danny Backx wrote:
> On Fri, 2009-09-04 at 10:41 +0200, Vincent R. wrote:
> > The problem about dll generated by cegcc and windows mobile >= 6.1 is due
> > to a  binary format
> > not respecting completely PE loader requirements and especially about PE
> > sections.
> > You should read cegcc archives and you will see the whole story.
> > If you want to see it by yourself, try do dump(with objdump or PE explorer)
> > binary section from a Visual Studio binary and 
> > from a cegcc one...
> 
> So I did that again :-) and found your message of 2009-01-30 saying :
> > - Then I started to analyze the issue with WM6.1 and dll generated by
> > cegcc, you can see some investigations here :
> > http://www.smartmobili.com/content/view/41/42/lang,fr/
> > 
> > The first problem I found was about Import Address Table that was
> > always
> > NULL while with Microsoft it's always filled. 
> > This issue has been fixed by kai Tiez(mingw-w64 maintener) and should
> > be
> > available
> > in binutils trunk. There are other differences but unfortunately I am
> > not a
> > binutils hacker and I don't know howto fix them so I think WM6.1 issue
> > will
> > be a bit difficult to fix for now.
> 
> Do you know the status of all this in binutils now ? Now that our gcc
> 4.4 environment is stable, this could be the next topic to look into.

On Sun, 2009-09-06 at 13:23 +0200, Vincent R. wrote:
> If my memory serves me right IAT issue was fixed by Kai Tietz but he
> didn't
> commit it because of a pseudo-relocation v1 issue.
> Actually I have never understood this pseudo-relocation stuff and
> especially why there was 2 versions (v1 and v2).
> Maybe you should ask on binutils.
> I think that to make it work it would be necessary to merge some
> sections
> (don't remember wich ones).
> Maybe a first plan would be to ask Kai to commit his patch, then
> update
> cegcc trunk with latest binutils and try
> to see if it changes something because I know that very regularly they
> make
> changes to be more compliant
> and to integrate more  PE format features (last feature is DLL delay
> loading and pseudo assembler support for SEH)


-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: binutils arm/PE issue causing failure on Windows Mobile 6.1+

[Kai Tietz]

Hello,

2009/9/6 Danny Backx <danny.backx@scarlet.be>:
> Hi,
>
> I'm forwarding w.r.t. an issue with cegcc (creating WinCE executables
> for ARM).
>
> We've had several reports over the last year, which were eventually
> tracked down to issues with the PE format exes we create.
>
> See some information about that below. Is the analysis by Vincent - that
> some stuff is still missing from binutils - correct ?
>
> Why is that, is there a way in which we can move forward ?
>
> Thanks,
>
>        Danny
>
> On Sat, 2009-09-05 at 12:04 +0200, Danny Backx wrote:
>> On Fri, 2009-09-04 at 10:41 +0200, Vincent R. wrote:
>> > The problem about dll generated by cegcc and windows mobile >= 6.1 is due
>> > to a  binary format
>> > not respecting completely PE loader requirements and especially about PE
>> > sections.
>> > You should read cegcc archives and you will see the whole story.
>> > If you want to see it by yourself, try do dump(with objdump or PE explorer)
>> > binary section from a Visual Studio binary and
>> > from a cegcc one...
>>
>> So I did that again :-) and found your message of 2009-01-30 saying :
>> > - Then I started to analyze the issue with WM6.1 and dll generated by
>> > cegcc, you can see some investigations here :
>> > http://www.smartmobili.com/content/view/41/42/lang,fr/
>> >
>> > The first problem I found was about Import Address Table that was
>> > always
>> > NULL while with Microsoft it's always filled.
>> > This issue has been fixed by kai Tiez(mingw-w64 maintener) and should
>> > be
>> > available
>> > in binutils trunk. There are other differences but unfortunately I am
>> > not a
>> > binutils hacker and I don't know howto fix them so I think WM6.1 issue
>> > will
>> > be a bit difficult to fix for now.
>>
>> Do you know the status of all this in binutils now ? Now that our gcc
>> 4.4 environment is stable, this could be the next topic to look into.
>
> On Sun, 2009-09-06 at 13:23 +0200, Vincent R. wrote:
>> If my memory serves me right IAT issue was fixed by Kai Tietz but he
>> didn't
>> commit it because of a pseudo-relocation v1 issue.
>> Actually I have never understood this pseudo-relocation stuff and
>> especially why there was 2 versions (v1 and v2).
>> Maybe you should ask on binutils.
>> I think that to make it work it would be necessary to merge some
>> sections
>> (don't remember wich ones).
>> Maybe a first plan would be to ask Kai to commit his patch, then
>> update
>> cegcc trunk with latest binutils and try
>> to see if it changes something because I know that very regularly they
>> make
>> changes to be more compliant
>> and to integrate more  PE format features (last feature is DLL delay
>> loading and pseudo assembler support for SEH)
>
>
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>
>

I have a patch for fixing IAT size for PE-coff. The issue why I didn't
posted it was, that the IAT for pseudo-relocation version 1 is badly
corrupt, and it makes no sense to output size here. For version 2 of
it, a proper IAT is written, as IAT and ILT have to be equal in size
and each has to be written as one block, but for pseudo-relocation
version 1 the IAT can be found all over the executable.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: binutils arm/PE issue causing failure on Windows Mobile 6.1+

[Danny Backx]

On Sun, 2009-09-06 at 18:38 +0200, Kai Tietz wrote:
> 2009/9/6 Danny Backx <danny.backx@scarlet.be>:
> > I'm forwarding w.r.t. an issue with cegcc (creating WinCE executables
> > for ARM).
> >
> > We've had several reports over the last year, which were eventually
> > tracked down to issues with the PE format exes we create.
>
> I have a patch for fixing IAT size for PE-coff. The issue why I didn't
> posted it was, that the IAT for pseudo-relocation version 1 is badly
> corrupt, and it makes no sense to output size here. For version 2 of
> it, a proper IAT is written, as IAT and ILT have to be equal in size
> and each has to be written as one block, but for pseudo-relocation
> version 1 the IAT can be found all over the executable.

I'm afraid you're way ahead of me. Is version 1 vs version 2 something I
could select as a build option when compiling an application ? Or does
it depend on other factors ?

It must not be as easy as that...

Where can I find info on version 1 vs version 2 ?

Thanks,

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: binutils arm/PE issue causing failure on Windows Mobile 6.1+

[Kai Tietz]

2009/9/6 Danny Backx <danny.backx@scarlet.be>:
> On Sun, 2009-09-06 at 18:38 +0200, Kai Tietz wrote:
>> 2009/9/6 Danny Backx <danny.backx@scarlet.be>:
>> > I'm forwarding w.r.t. an issue with cegcc (creating WinCE executables
>> > for ARM).
>> >
>> > We've had several reports over the last year, which were eventually
>> > tracked down to issues with the PE format exes we create.
>>
>> I have a patch for fixing IAT size for PE-coff. The issue why I didn't
>> posted it was, that the IAT for pseudo-relocation version 1 is badly
>> corrupt, and it makes no sense to output size here. For version 2 of
>> it, a proper IAT is written, as IAT and ILT have to be equal in size
>> and each has to be written as one block, but for pseudo-relocation
>> version 1 the IAT can be found all over the executable.
>
> I'm afraid you're way ahead of me. Is version 1 vs version 2 something I
> could select as a build option when compiling an application ? Or does
> it depend on other factors ?
>
> It must not be as easy as that...
>
> Where can I find info on version 1 vs version 2 ?
>
> Thanks,
>
>        Danny
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>
>

Hello Danny,

as far as I know, there is just some technical documentation in
comments of ld's pe-dll.c about it. But I try to summarize where the
difference are between those two different pseudo-relocation
implementation - Dave if you think I missed here something, please
comment, too.

The pseudo-relocation version 1 (afterward just as v1) uses for each
auto-imported symbol an new import table (even for same symbol
multiple times), as it sets the IAT RVA address within code/data
section, where it occurs. Additionally there is the the
pseudo-relocation table - which is handled by startup code - which
adds necessary deltas to the the relocation. By this you can see that
by v1 the PE header is growing pretty much for and it needs that code
and read-only section have to have write privileges for startup-code.
Additionally there is no block of IATs, and the size of relocation has
to have IMAGEBASE_RELOC size.

For base relocation version 2 (afterward as v2) symbol gets just once
imported and the IATs are placed into one coherent block. By this for
each import table the IAT can be exported with proper size. The
pseudo-relocation table - which is handled by startup code - contains
the location and size of relocation - handles to change for
modification the write-privilege temporary and is able to do
relocations <= IMAGEBASE_RELOC. By v2 the pe-header gets smaller and
there is no need to change section write-privilege by linker anymore.
Also it allows to handle const struct, and smaller relative
relocations without issue.

v1 is at the moment AFAIK default for cygwin and windows 32-bit
targets. For 64-bit window target v2 is already default, as v1 isn't
usable for it at all.

I hope I could give you some help

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: binutils arm/PE issue causing failure on Windows Mobile 6.1+

[Danny Backx]

On Sun, 2009-09-06 at 21:25 +0200, Kai Tietz wrote:
> 2009/9/6 Danny Backx <danny.backx@scarlet.be>:
> > Where can I find info on version 1 vs version 2 ?
>
> as far as I know, there is just some technical documentation in
> comments of ld's pe-dll.c about it. But I try to summarize where the
> difference are between those two different pseudo-relocation
> implementation - Dave if you think I missed here something, please
> comment, too.
>
> v1 is at the moment AFAIK default for cygwin and windows 32-bit
> targets. For 64-bit window target v2 is already default, as v1 isn't
> usable for it at all.

Thanks. Very interesting. I'm looking into that documentation.

Your explanation makes it look like we're waiting for someone to port v2
to the 32-bit targets.

Is that all there is to it, or are there more issues ?

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info