--enable-auto-import extension

[Charles Wilson]

egor duda wrote


> CW> But why is this cygwin-specific?  It seems that it's equally applicable 
> CW> to mingw (e.g. native) DLLs, just as mingw's gcc can use the current 
> CW> auto-import feature, even though MSVC can't understand or use it...
> 
> Well, of course it shouldn't be. I was thinking in terms of cygwin,
> and, lacking better name, called it "cygwin blah-blah". But
> suggestions for more generic name are welcome.


"cygwin internal pseudo-relocation"
-->
"pei386 runtime pseudo-relocation" ?

I think "pseudo-relocation" is an apt term to describe what your patch 
does.  Instead of marking the location of the "object" in memory, and 
expecting the runtime loader to (a) update that to the REAL location in 
memory and THEN (b) tack on an additional addend, you (a) create a 
pseudo-object at the memory location "object location + addend" and (b) 
let the windows runtime loader perform addend-less relocation on the 
psuedo-object.

So, it's runtime pseudo-relocation.  Sorta.

> DLL is not changed in any way! Changes are made in _client_ code. So,
> cygintl-*.dll stays as it was, and exports exactly the same symbols as
> before. It should be, i believe, byte-to-byte identical to the dll
> built with old ld.


I see that now.


> If client has no relocations with non-zero addend, i.e. it was
> "auto-import-compatible", then nothing changes too. If your old code
> could be linked with --enable-auto-import, then my added code is never
> called.


Yep.  (not tested, but seems obvious now from the code)


> CW> Q3: Is the new DLL usable by windows tools, provided a suitable import 
> CW> library is generated? (I'm thinking here of mingw folks who build DLLs 
> CW> and implibs for use by others with MSVC -- granted, MSVC can't use 
> CW> auto-import at all, much less your extention.  But the same linker will 
> CW> be used even to build "regular" DLLs...we can't break that.)
> 
> DLL is not changing.


Yep.


>>>1. Make cygreloc generation conditional via --enable-cygwin-reloc or
>>>something like that.
>>>
> 
> 
> CW> At first, yes, it does need to be conditional -- and default to OFF, 
> CW> probably...
> 
> CW> And, it should probably not be "cygwin" specific.  --enable-data-reloc?
> 
> Actually, it's not necessarily data reloc, though with probability of
> 99%+ it probably-is. Maybe '--enable-runtime-reloc'?


I like 'pseudo' so much (even if I have to check e/u u/e every time) 
that I'd prefer:

'--enable-runtime-pseudo-reloc'


> CW> (cygreloc -->> addend_reloc?)
> 
> It goes to client.


Yes, I see.  (cygreloc --> pei386_pseudo_reloc?  more typing, but more 
accurate, and general)


> Such things are handled by compiler. As far as i understand, all
> relocations in coff files are 1) "linear" (base+addend), 2)
> independent (i.e. order in which you make them doesn't matter).
> I've attached a modified test to demonstrate this.


Verified.  Thx.


> What i was talking about is 64-bit versions of windows where addresses
> (and so base symbol values and addends are 64-bit). Or if we want to
> add some other types of relocations. Adding type field will make it
> possible to add extensions to this feature.


</sheepish> Yeah.  What he said.  <I'll be over here....>

> Of course. Luckily, all we have to check is that it doesn't change
> binaries for existing code, 


Hard to do, really -- DLLs get a timestamp in their header, so even 
under ideal conditions you can't do a simple diff on two DLLs...I 
suppose you could make sure that two DLLs differ ONLY in "unimportant" 
ways, like timestamp.

> and then check clients one-by-one.


That's a long term effort. <g>

BTW, the example code you sent is needlessly complex; you don't need a 
special DLLMain() function.  Also, ld will automatically hunt for 
"libfoo.dll.a" if you give it a "-lfoo" flag -- there's no need for 
"-lfoo.dll".

See attached patch -- works fine here, with your modified ld.

--Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: egor_simplify.patch
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20020701/c8c474c7/attachment.ksh>