This is the mail archive of the cygwin 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: help with dynamic linkage?


On Sat, 11 Feb 2006, skaller wrote:

> On Sat, 2006-02-11 at 00:59 -0500, Igor Peshansky wrote:
> > On Sat, 11 Feb 2006, skaller wrote:
> >
> > > hi, I'm having some problem getting dynamic linkage to work.
> > > The linkage model is like this:
> > >
> > > mainline <----- load time ---- librtl.dll
> > > ^                               /
> > >  \                             /
> > > dlopen                        /
> > >    \                         /
> > >   user.dll <-----------------
> > >
> > > gdb indicates the code is crashing in dlopen. LoadLibrary
> > > doesn't appear to work either :)
>
> > In fact, a small example program, buildable with a makefile into two
> > DLLs and a main application, would be even more helpful.
>
> I have tried that .. it works :) Basically the original instructions
> on the website say to use -Wl,-auto-import ... blah blah in the advanced
> explanations suff. But the simplified example doesn't use that.
> Neither do I. I did try building an export/import lib. That does seem
> to change the time and way the system crashes.
>
> The crash occurs when an attempt is made to load the user.dll,
> even when the filename given is rubbish .. so the problem isn't
> related to that dll. The program WORKS when no filename is
> given, in which case it just prints the usual 'usage' information.
>
> In the case of a garbage filename, the rtl should be throwing
> a C++ exception. Perhaps that's causing the problem. However
> in the case of a valid filename it should work .. but I get
> the same result.
>
> Unfortunately the only easy way to reproduce the problem is to
> download and install Felix:
>
> 	http://felix.sf.net/flx_1.1.2_rc1.tgz

Well, you could have done *some* work on cutting the testcase down,
especially since you know the code better than I do.  But, since I'm the
Cygwin O'Caml maintainer, I was curious, so I downloaded it (turns out the
problem has nothing to do with O'Caml).  Starting with the make log and
the generated C++ version of the code, I ended up with the attached files.
FWIW, it seems to be crashing in the flx_dynlink_t destructor (not in
dlopen) -- in fact, even before I cut it down to the attached, commenting
out any mention of dlopen still caused the crash.  Stepping through the
code in gdb quickly gets you to the place where it crashes.

> which requires Python and Ocaml. After that ./configure, make
> should work. Then make test. BTW: if any Cygwin expert would
> like to join the project that would be great!
>
> > Then wouldn't you be able to reproduce it with only one DLL and one
> > main application?  Can we see a small complete example that shows the
> > problem?
>
> As above .. small C example, as given on the Cygwin website, works
> just fine.
>
> The problem could be related to C++ RTTI, since I know
> ELF/gcc 4.0 doesn't work correctly it would be unfair to expect
> gcc 3.4 on Cygwin to do all that nasty emulation and work.
>
> (The problem here is related to duplicate typeinfo records,
> which cannot be avoided in general with dynamic linkage.
> Some care is needed in the code to ensure the RTTI is only
> instantiated once, and properly imported from that one
> location, because gcc's method of catching exceptions
> is broken)
>
> However no exception should be thrown when loading one
> of the proper dlls with dlopen(), so there could be
> two distinct faults.
>
> It's also possible -O3 -fomit-frame-pointer is the problem:
> gcc's -O3 is known to not work reliably. (however if I recall
> I got rid of both, and it made no difference).
>
> > > Info: resolving vtable for XXXby linking to __imp__XXX (auto-import)
> > >
> > > occur when linking the executable.
> >
> > Those are informational.  You can either ignore them, or give the
> > "-Wl,--enable-auto-import" flag to the linker to quiet them.
>
> I admit being confused what that does. According to my understanding
> of it, this auto-import thing should only apply to variables.
> vtables and code are read only, they should be in the code (text)
> segment shouldn't they?

I'm not sure.  Technically, vtables are data (though they contain pointers
to the code).  But I'm not a C++ internals expert, and this is not a C++
internals list... :-)  Besides, that's irrelevant to your crash.

> > > Cygwin: latest setup provides.
> >
> > Umm, setup can provide quite a few versions ranging from ancient to
> > latest, depending on your mirror.  Why not follow the guidelines at
> > <http://cygwin.com/problems.html> and attach (as an uncompressed text
> > attachment) the output of "cygcheck -svr"?
>
> Done, for the XP64 machine. The other I can't get atm, since
> its dual booted with Linux which is running my mail client :)
>
> > > Any hints what is causing the problem or how to fix it?
> >
> > Not until we have enough information to allow us to reproduce the
> > problem.
>
> I need some hint of what it could be to try to reduce
> the 100KLoc to a manageable size :) It has to be something

As I said above, this has nothing to do with dynamic linkage.  And cutting
this down was relatively easy (if tedious) -- just start with main(), keep
removing functionality until it doesn't crash anymore, then put the last
removed piece back in and start removing finer-grained functionality.

> related to different ways Linux and Cygwin handle dynamic linkage,
> interacting with some other feature -- such as threads, exception
> handling, linkage technique/dll startup code, etc etc.
>
> One difference: on Linux I have to use -lpthread, on Cygwin
> that seems unnecessary. I did try rebuilding with it.

The pthreads functionality is built into cygwin1.dll.

> > FWIW, I was unable to reproduce this with a trivial instance of your
> > scheme above and default linker options.
>
> Neither was I.
>
> >   One quick question: how are you
> > invoking functions from user.dll, are you getting the right function
> > pointer, and are you taking care of C++ name mangling when loading symbols
> > from the DLL?
>
> I think so: it works on Linux, OSX, -mno-cygwin, MSVC++ etc.
> All the dlsym() symbols are extern "C".
>
> However, the rtl is not dlopen()ed.

This looks to me like another instance of
<http://cygwin.com/ml/cygwin/2006-01/msg00113.html> (follow that thread
through -- it has a reference to another thread, too).
HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Attachment: Makefile
Description: Text document

Attachment: flx_run.cxx
Description: Text document

Attachment: flx_dynlink.cpp
Description: Text document

Attachment: flx_dynlink.hpp
Description: Text document

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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