Guys, I had posted a really small dll and some pointers here, a while ago: https://sourceforge.net/mailarchive/message.php?msg_name=200809221536.59800.alves.ped%40gmail.com
(quoted below) Maybe you can merge your new findings with those, and see if something pops up? -- Pedro Alves On Monday 22 September 2008 15:36:59, Pedro Alves wrote: > 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. > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
