This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: --enable-auto-import extension


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

diff -u egor2/Makefile egor2-new/Makefile
--- egor2/Makefile	2002-07-01 17:05:59.000000000 -0400
+++ egor2-new/Makefile	2002-07-01 17:05:35.000000000 -0400
@@ -16,7 +16,7 @@
 	$(CC) -shared -o crtest.dll $(DLL_LDFLAGS) $<
 
 crtest.exe: crtest.o libcrtest.dll.a
-	$(CC) $(EXE_LDFLAGS) -o crtest.exe crtest.o -L. -lcrtest.dll
+	$(CC) $(EXE_LDFLAGS) -o crtest.exe crtest.o -L. -lcrtest
 
 .PHONY: clean
 
diff -u egor2/crtest_dll.c egor2-new/crtest_dll.c
--- egor2/crtest_dll.c	2002-07-01 17:05:59.000000000 -0400
+++ egor2-new/crtest_dll.c	2002-07-01 17:05:35.000000000 -0400
@@ -1,36 +1,4 @@
-#define WIN32_LEAN_AND_MEAN
-#include <windows.h>
-#undef WIN32_LEAN_AND_MEAN
-#include <stdio.h>
-
-#include <cygwin/cygwin_dll.h>
-
 #include "crtest.h"
 
 foo_t foo[2] = { {1, {11, 12, 13}, {'a', 'b', 'c'}},
                  {2, {21, 22, 23}, {'d', 'e', 'f'}}};
-
-DECLARE_CYGWIN_DLL(DllMain)
-BOOL APIENTRY
-DllMain (
-	 HINSTANCE hInst /* Library instance handle. */ ,
-	 DWORD reason /* Reason this function is being called. */ ,
-	 LPVOID reserved /* Not used. */)
-{
-  switch (reason)
-    {
-    case DLL_PROCESS_ATTACH:
-      break;
-
-    case DLL_PROCESS_DETACH:
-      break;
-
-    case DLL_THREAD_ATTACH:
-      break;
-
-    case DLL_THREAD_DETACH:
-      break;
-    }
-  return TRUE;
-}
-

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]