On Fri, 06 Nov 2009 02:03:41 +0000, Dave Korn
<[email protected]> wrote:
> Vincent R. wrote:
>
>>> So Dave, question coundn't we manually change .idata section
>>> characteristics for instance instead of disabling auto-import ?
>>
>>
>> Ok I just tried to modify .idata section characteristics by removing
>> write
>> attributes and of course now I don't even have an error message,
nothing
>> happens.
>
> Yep; if you are using auto-import, you have to have writeable .rodata
> sections, and since WM/CE doesn't allow that, it looks like auto-import
is
> screwed on WMCE and your choices are either 1) annotate all w32api
headers
> with dllimport, or 2) get v2 pseudo-relocs working.
>
Anyway for the moment I am focusing on a simple sample application loading
a dll that exports a single function and I am using declspec
>> .idata section BUT IAT needs to have write access. In french we have an
>> expression that could be translated by "a snake swallowing its own
>> tail"...
>
> In Liverpool we talk about Our Rob or Ross ...
>
>> Second issue is .bss and from my limited knowledge of low level stuff
>> this
>> is the place where should go uninitialized data but of course they
might
>> be
>> received a value during program execution so once again they need write
>> attribute. So I would recommend to put .bss in .data. Of course I
cannot
>> guarantee it will sove our issue but this is the only thing I can
propose
>> for now.
>
> The real problem here (I think, without having recently built cegcc
and
> tested it) is that auto-import works by scattering little import tables
> throughout the .text, .data and even (and this is a particular part of
the
> problem) .rodata section(s) of your exe. That means they have to be
made
> writable, otherwise when the run-time loader tries to fix up all the IAT
> entries, it will SEGV - it knows enough to make the .idata section
> writeable,
> but that doesn't help because auto-import works by putting import tables
in
> other places.
>
> That's not a problem on (e.g.) the windows PE platforms, because the
> runtime
> loader there is less strict, but what I think we've all found out over
the
> past little while is that the WMCE loader is much more rigorous about
the
> executable image file format.
>
> Pseudo-relocs v2. solves this problem by not (ab)using the runtime
> loader's
> import resolution facility at all, but by keeping track of all the
imported
> addresses in a list, and running a bit of code at CRT startup time that
> switches the relevant pages into read/write mode before relocating the
> imports, thus avoiding the access violation that crashes the runtime
> loader.
> I would expect that to solve the problem on WMCE too.
>
I would like to use pseudo-reloc v2 and I have even enabled it as the
default mechanism
in emultempl/pe.em
L171: link_info.pei386_runtime_pseudo_reloc = 2; /* Use by default
version 2. */
...
L731: case OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC:
link_info.pei386_runtime_pseudo_reloc = 2;
break;
I have also applied another patch that I think is supposed to fill IAT
value and I have
recompiled binutils but when I clean/recompile my sample application I
cannot see any differences
in binary code, IAT is still NULL. Do I need to also recompile
w32api/mingw ?
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cegcc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
