From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13446 invoked by alias); 1 Jul 2002 21:28:23 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 13421 invoked from network); 1 Jul 2002 21:28:19 -0000 Received: from unknown (HELO mail.ee.gatech.edu) (130.207.225.105) by sources.redhat.com with SMTP; 1 Jul 2002 21:28:19 -0000 Received: from ece.gatech.edu (ibb-407.ibb.gatech.edu [128.61.133.57]) by mail.ee.gatech.edu (8.12.3/8.12.1) with ESMTP id g61LSHrA021159; Mon, 1 Jul 2002 17:28:17 -0400 (EDT) Message-ID: <3D20C981.8020407@ece.gatech.edu> Date: Mon, 01 Jul 2002 14:28:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: egor duda CC: cygwin-apps@sources.redhat.com Subject: Re: --enable-auto-import extension References: <1212929671.20020628141818@logos-m.ru> <3D1D08A1.9070505@ece.gatech.edu> <180259441557.20020701104656@logos-m.ru> Content-Type: multipart/mixed; boundary="------------020600080905000107090206" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-SW-Source: 2002-07/txt/msg00016.txt.bz2 This is a multi-part message in MIME format. --------------020600080905000107090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 3924 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. Yeah. What he said. > 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. 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 --------------020600080905000107090206 Content-Type: text/plain; name="egor_simplify.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="egor_simplify.patch" Content-length: 1303 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 -#undef WIN32_LEAN_AND_MEAN -#include - -#include - #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; -} - --------------020600080905000107090206--