Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Wed, 3 May 2000 17:24:23 +0300 From: Paul Sokolovsky X-Mailer: The Bat! (v1.32) S/N A9B97A11 Reply-To: Paul Sokolovsky X-Priority: 3 (Normal) Message-ID: <15725.000503@is.lg.ua> To: DJ Delorie CC: cygwin AT sourceware DOT cygnus DOT com Subject: Re[2]: Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases In-reply-To: <200005031210.IAA08335@envy.delorie.com> References: <200005031210 DOT IAA08335 AT envy DOT delorie DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello DJ, Wednesday, May 03, 2000, 3:10:44 PM, you wrote: >> DD> You can't put them in the .def file yourself? >> >> If I will put data symbols in defs myself for every X-Server, >> GNOME, KDE, etc. which I'm going to port, I will hardly port single. >> Which is exactly the current situation ;-) DD> An automated porting effort using DLLs with data is going to be hard DD> anyway. Either way, you *must* modify the sources to understand that DD> the data is coming from the DLL, or it won't work. Ha, that's the effect of stereotypes! It is at runtime, at the point of specific variable access the decision on how to access it should be unavoidably made: either access var directly or via extra level of inderection. So, one extreme make this decision at the point of compiling high-level source code, as MS did it. Other is make decision at runtime, immediately before each access. The latter of course sounds crazy. Then, why the other extreme must be much better? We accept dllimport as necessary unavoidable evil, while it can be doubted that that is adequate level to address problem. In similiarity with literate programming I'd call that "literate linking" ;-) Well, writing documentation side-by-side with source is probably good, but stuffing source code with instructions helping with dynamic linking should not be taken as dogma. There's at least two places in between where transform might happen - when linking objects into executable and when producing the objects themselves. There's almost no difference between the two, only in first case it needs to cope with machine code, so I've choosen second. Idea is post-process assembly of some object, having defs for each dll it should be linked with. Accesses of DATA symbols listed in defs transformed appropriately. Of course, this in general case means at least 4-fold overhead (push-load-indirect-pop), so there's register data flow analysis which in most cases eliminates necessity to preserve indirection register, so resulting code not so much inefficient comparing to generated by gcc with dllimports. Of course, that's quite hard to integrate in adhoc manner into naive building system. But it quite nice fits into libtool's approach, which already does many complex and obscure things. So far I built all libtool demos without changes using this and couple of other approaches. >> Strange, it seems to be really nondeterministic bug. I deleetd >> ... DD> Odd. I don't suppose you could check the sources and see if it's DD> an easily fixable bug, could you? I'm kinda busy at the moment. DD> The code is probably in ld/pe-dll.c Yes, for sure I queued this and other misfeatues I wrote about for fixing. But for now doing something impossible is more priority for me ;-) Btw, as I wrote, I don't see what is wrong with that dll which does not load. So, to fix that it's probably will require first read many PE docs and make many experiments. >> Such rule would be nice for msvc manual, but hardly for gcc's. >> Whole talk about porting stuff to win32, not writing own. It was DD> Then the easy solution is "don't use dlls". Link statically. First, static linking is wastage and underfunctionality. Then, linking megabytes statically is not easy solution for my p5-100-24M. But even on more powerful systems I'd prefer to stuff memory with data and not code. >> all. If Unix lives without them, win32 will live also. Period. ;-) DD> Except Unix has elf shared libraries, which are designed for the way DD> Unix needs them to work. My idea is the same: it's almost impossible to design something to disallow some way of making it work in normal way. Best regards, Paul mailto:paul-ml AT is DOT lg DOT ua -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com