This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: --enable-auto-import extension
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: egor duda <binutils at sources dot redhat dot com>
- Cc: cygwin-apps at sources dot redhat dot com
- Date: Mon, 01 Jul 2002 17:28:33 -0400
- Subject: Re: --enable-auto-import extension
- References: <1212929671.20020628141818@logos-m.ru> <3D1D08A1.9070505@ece.gatech.edu> <180259441557.20020701104656@logos-m.ru>
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;
-}
-