On Monday 22 September 2008 08:34:20, Jérôme Decoodt wrote:
> Hello,
>
> This post seems to be related to our problem:
> http://blogs.msdn.com/hopperx/archive/2008/09/19/writeable-code-sections-go
>t-you-down-fear-no-more.aspx
>
> Hopping this can help some gurus on resolving the issue,
Indeed it's helpful. Thanks for the pointer. I've tracked this
down to something around the export data directory or the import data
directory. On our toolchain, we put them each on their own section
(.edata, .idata), while MSFT puts them all merged in one
section (.rdata).
MSFT:
Idx Name Size VMA LMA File off Algn
0 .text 0000006c 10001000 10001000 00000400 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rdata 00000113 10002000 10002000 00000600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00010008 10003000 10003000 00000800 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .pdata 00000010 10014000 10014000 00010a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .reloc 00000024 10015000 10015000 00010c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The Data Directory
Entry 0 00002060 0000004a Export Directory [.edata (or where ever we found
it)]
Entry 1 0000201c 00000028 Import Directory [parts of .idata]
Entry 2 00000000 00000000 Resource Directory [.rsrc]
(nevermind the .edata and .idata references, those are hardcoded, notice
the addresses instead, which both point at .rdata)
ld:
Idx Name Size VMA LMA File off Algn
0 .text 00000078 10001000 10001000 00000400 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00010000 10002000 10002000 00000600 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .edata 0000004a 10012000 10012000 00010600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .idata 00000058 10013000 10013000 00010800 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .reloc 0000000c 10014000 10014000 00010a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The Data Directory
Entry 0 00012000 0000004a Export Directory [.edata (or where ever we found
it)]
Entry 1 00013000 00000058 Import Directory [parts of .idata]
Entry 2 00000000 00000000 Resource Directory [.rsrc]
...
(each points at its own section, which means there's a gap between
them. Plus, .idata comes after .edata, while MSFT puts it the
other way around. I don't think this is invalid according
to the PE specification, but you never know what assumptions MSFT
is making in the loader, due to only looking at binaries produced
by their toolchain ...)
Another think I noticed is that it doesn't have to the code section
that's too big, .data or .bss also trigger the issue. E.g., a dll
with only this also refused:
static char big_buf[0x10000];
BOOL APIENTRY _DllMainCRTStartup( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
Also, I noticed that if we strip the import or export directories out
of a problematic dll (in the case above, they're empty anyway), it
loads sucessfully.
Now, I wonder if making .idata readonly too (as per the article you
pointed, although these are not marked as CODE, but you never know...)
would solve it.
Perhaps putting .edata and .idata right after .text
would be needed too. Or putting .idata before .edata as MSFT seems
to be doing.
Pending those not working, putting the export and import directories
in the same section as MSFT does may fix it, as I don't see any other
differences. A least it would save us a few bytes on every dll :-).
Other than that, I currently have no more other ideas.
--
Pedro Alves
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
