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: Segfault in _cygwin_dll_entry


On Wed, 11 Feb 2004 peda@sectra.se wrote:

> > The difference, althought it really doesn't matter, is that
> > libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't.  Something in the
> > makeup of cygggi-2.dll causes the same condition as when libzsh-4.1.1.dll
> > is rebased.
>
> I found a couple of __declspec(dllexport) and __declspec(dllimport) from
> a previous attempt at porting GGI to cygwin/mingw. When I removed these
> the segfault disappeared.

Thanks!  That was one of the missing pieces!  Ok, I'm attaching a script
which illustrates the problem in a very simple form (it's the distilled
form of how zsh's dlls are built and, I suspect, how cygggi-2.dll was
built as well).

The script creates two very simple source files, one a program main
(testmain.c), one a simple dll (testdll.c), compiles them, uses dllwrap
to create a dll, then runs the program to show it works, and then rebases
the dll and runs it again to show the failure.  The script also does a
complete objdump of the dll before and after the rebase.

The important thing to note is that there is a symbol in the dll called,
aptly enough, "_image_base__", which appears to be used by something, of
which I know not what.  But, the fact that this symbol has the same value
as the dll's original image base must mean something.  Rebase, obviously,
does not look for this symbol and does not change it's value.  For grins,
I edited the rebased dll with a hex editor or manually changed the value
to be the new image base address and, whamo!, it runs!

Now, the source in this example uses __declspec(dllexport) to export the
symbol (test_main in this case), and the object file thus contains a new
section which I'm not directly familiar with: .drectve

This section has the following content for our little test:

Contents of section .drectve:
 0000 202d6578 706f7274 3a746573 745f6d61   -export:test_ma
 0010 696e0000                             in..

And to dllwrap (or rather gcc) this section means something and causes
the symbol "_image_base__" to be set in the dll to the imagebase for the
dll.  If you remove/comment the __declspec stuff from the test source and
re-run it, the object file does not have the mystery section and the
subsequent dll doesn't have "_image_base__" set it in, and everything
runs well, rebased or not.

So, this is the cause of the error.  Now, for the question: should we not
be using __declspec(dllexport)/__declspec(dllimport) or should rebase be
updated to look for this symbol and change it's value accordingly?

Enquiring Minds Want To Know!!!

> Regards,
> Peter Ekberg

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Attachment: testscript.sh
Description: testscript.sh

--
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]