Mail Archives: cygwin-apps/2002/04/28/08:13:29
> > > Well then, this is only half the puzzle. I can see what you
> > gain from
> > > such a patch, but as Chuck as indicated, it will cause -major-
> > > difficulties in management.
> > Do you have read the rules I have stated for kde ?
> > > We'd probably also need to ensure that strip leaves the
> > names in the
> > > IAT (I wasn't clear from your other email whether it does that or
> > > not).
> > >
> > Yes it does. See some parts about my auto-import documentation.
> > $ objdump -x client.exe
> > FirstThunk (2) points to the import address table (IAT),
> > which entries are identifed by corresponding _imp_... symbols.
> The IAT is an array of IMAGE_THUNK_DATA, that gets overwritten by the
> physical PE header of the linked image by the win32 .exe load process.
> > HintTab (3) point to a rva (relative virtual address = offset
> > from image start) vector pointing to IMAGE_IMPORT_BY_NAME unions.
> Huh? The Hinttab->hintname array is an array of IMAGE_THUNK_DATA.
yes. The entries poing to the IMAGE_IMPORT_BY_NAME.
> > (4) shows an IMAGE_IMPORT_BY_NAME union for a named link. It
> > is identifed by the _nm_<smbol> name . In this structure the
> > symbol name string is stored independed from the regular
> > symbol name, which can be only stripped.
> Hmm. the diagram above is a little misleading. The IMAGE_IMPORT_BY_NAME
> struct is not a union. It's IMAGE_THUNK_DATA that is a union, and for
> named imports contains that RVA of the IMAGE_IMPORT_BY_NAME struct,
> which has both the ordinal and the member name. Lastly there is _no_
> requirement for the INT and IAT to share IMAGE_IMPORT_BY_NAME structs,
> and they definitely won't share IMAGE_THUNK_DATA elements.
Thank for this hint. In this case I was wrong.
- Raw text -