Hello, > > > (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. > > > > I haven't looked at where this is comming from, but I tried removing > those with PE Explorer (great app for these matters, btw), and the > result was the same.
I played with PE Explorer too and changed some permissions on some sections. Putting a write attribute on sections often cause crash very weird where there is two crash reports and you cannot remove the DLL (there must be a leak on the access refcount). > > > 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). > > > > You seem to have ways to go deeper into CE system debugging than > I have... I just found this on debuging with Visual, looking in the assembler view where the dll were loaded. With my light DLL, I could see all the .text section while with a standard DLL, only the first 64kB were visible. > One think I just noticed is that we're not setting the > Import Address Table in the directory entries, while a dll built > with MSFT's tools does set it, and its contents are in .data. Could > this be related? According to the wince headers, this entry doesn't seem to be used (in pehdr, it is marked as reserved, and a comment say only the first 7 entries are used). The loader seems to write resolved addresses directly in the import table. Did you try to delete the IAT entry in PE Explorer? > > > 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 :/ > > > > The attached is a gross hack at it. Warning, stripping breaks the hack. > > It doesn't look like this is enough either... dll loads on mobile 6, > fails to load on mobile 6.1. Could the issue be the IAT not > being set? I'm recompiling the whole toolchain with the hack to see and I'll come back after testing it... Best regards, -- 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
