Hello, > 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).
I tried to modify binutils/bfd/peXXigen.c to have .idata without write attribute and my previous test case is loading successfully. But if I compile with all the CRT stuff (a DLL with DllMainCRTStartup), the application crash at load. When looking at the crash, the problem is that only the first 64kB is loaded and DllMainCRTStartup try to call a function after those 64kB, causing a page exception. Compiling without the CRT stuff load all the code. I'm searching why there is such a difference. > (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 ...) This seems perfectly valid to the PE spec, except some bits in the characterics of sections: some sections contain bits 0x00300000 (align group?) which seem invalid for a final executable. According to the post on msdn, we couldn't know the loader will crash if there is a writable section of code... > 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: Indeed, we just need to be put in high memory, so just having a SizeOfImage > 0x10000 in the PE header is enougth. > 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. Indeed, the crash seems to be in the DoImports function of wince loader. The faulting code (test in a loop on dll names to be linked to) is not reached if there is no import table or if the size is 0. > 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. It doesn't seem to be enougth, as all the code is not loaded in memory when I put the standard DllMainCRTStartup (I recompiled all the toolchain after changing the defaut permissions on the .idata section). > 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. Yes, putting .idata and .edata in a single section could be a good thing to try, unfortunately, I don't think I'll be able to do this :/ Thanks for your involvement, -- Jérôme Decoodt ------------------------------------------------------------------------- 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
