Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Wed, 3 May 2000 17:24:23 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Message-ID: <15725.000503@is.lg.ua>
To: DJ Delorie <dj AT delorie DOT com>
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