Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 12 Feb 2004 22:56:44 -0800 (PST) From: "Peter A. Castro" To: peda AT sectra DOT se cc: cygwin AT cygwin DOT com Subject: Re: Segfault in _cygwin_dll_entry In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811071-1306756812-1076655404=:28458" X-IsSubscribed: yes ---1463811071-1306756812-1076655404=:28458 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Feb 2004 peda AT sectra DOT 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 or "Cats are just autistic Dogs" -- Dr. Tony Attwood ---1463811071-1306756812-1076655404=:28458 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="testscript.sh" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: testscript.sh Content-Disposition: attachment; filename="testscript.sh" IyEvYmluL2Jhc2gNCg0KZWNob2RvKCkNCnsNCiBlY2hvICIkKiINCiBldmFs ICIkKiINCn0NCg0KZWNobyAiIyMgQ3JlYXRpbmcgdGVzdGRsbC5jIHNvdXJj ZSINCmNhdCA8PCBFT0YgPiB0ZXN0ZGxsLmMNCiNpbmNsdWRlIDxzdGRpby5o Pg0KDQpfX2RlY2xzcGVjKGRsbGV4cG9ydCkNCmludCB0ZXN0X21haW4oaW50 IGFyZ2MsIGNoYXIgKiphcmd2KQ0Kew0KICAgIHByaW50ZigiaGVsbG9cbiIp Ow0KfQ0KRU9GDQoNCmVjaG8gIiMjIENyZWF0aW5nIHRlc3RtYWluLmMgc291 cmNlIg0KY2F0IDw8IEVPRiA+IHRlc3RtYWluLmMNCiNpbmNsdWRlIDxzdGRp by5oPg0KDQpfX2RlY2xzcGVjKGRsbGltcG9ydCkNCmV4dGVybiBpbnQgdGVz dF9tYWluKGludCBhcmdjLCBjaGFyICoqYXJndik7DQoNCm1haW4oaW50IGFy Z2MsIGNoYXIgKiphcmd2KQ0Kew0KICB0ZXN0X21haW4oYXJnYyxhcmd2KTsN Cn0NCkVPRg0KDQplY2hvICIjIyBDb21waWxpbmcgdGVzdGRsbC5jIC0+IHRl c3RkbGwubyINCmVjaG9kbyAiZ2NjIC1nIC1jIHRlc3RkbGwuYyINCg0KZWNo byAiIyMgQ3JlYXRpbmcgdGVzdGRsbC5kbGwiDQplY2hvZG8gImRsbHdyYXAg LWcgLS1leHBvcnQtYWxsLXN5bWJvbHMgLW8gdGVzdGRsbC5kbGwgdGVzdGRs bC5vIC1sYyINCg0KZWNobyAiIyMgQ29tcGlsaW5nIHRlc3RtYWluLmMgLT4g dGVzdG1haW4ubyINCmVjaG9kbyAiZ2NjIC1nIC1jIHRlc3RtYWluLmMiDQoN CmVjaG8gIiMjIExpbmtpbmcgdGVzdG1haW4ubywgdGVzdGRsbC5kbGwgLT4g dGVzdG1haW4uZXhlIg0KZWNob2RvICJnY2MgLWcgLW8gdGVzdG1haW4gdGVz dG1haW4ubyB0ZXN0ZGxsLmRsbCAtbGMiDQoNCmVjaG8gIiMjIFJ1bm5pbmcg dGVzdG1haW4uZXhlLCBzaG91bGQgcHJvZHVjZSAnaGVsbG8nIg0KZWNob2Rv ICIuL3Rlc3RtYWluIg0KDQplY2hvICIjIyBHZXR0aW5nIG9iamR1bXAgb2Yg Y2xlYW4gdGVzdGRsbC5kbGwgZm9yIGxhdGVyIHBlcnVzYWwiDQplY2hvZG8g Im9iamR1bXAgLWEgLWYgLXAgLXggLWQgLUQgLVMgLXMgLWcgLWUgLUcgLXQg LVQgLXIgLVIgdGVzdGRsbC5kbGwgPiB0ZXN0ZGxsLmRsbC5vYmpkdW1wIg0K DQplY2hvICIjIyBTYXZpbmcgY2xlYW4gdGVzdGRsbC5kbGwgYW5kIG9iamR1 bXAiDQplY2hvZG8gImNwIC1hIHRlc3RkbGwuZGxsIHRlc3RkbGwuY2xlYW4u ZGxsIg0KZWNob2RvICJjcCAtYSB0ZXN0ZGxsLmRsbC5vYmpkdW1wIHRlc3Rk bGwuY2xlYW4uZGxsLm9iamR1bXAiDQoNCmVjaG8gIiMjIFJlYmFzaW5nIHRl c3RkbGwuZGxsIg0KZWNob2RvICJyZWJhc2UgLXYgLWQgLWIgMHg3MDAwMDAw MCAtbyAweDEwMDAwIHRlc3RkbGwuZGxsIg0KDQplY2hvICIjIyBHZXR0aW5n IG9iamR1bXAgb2YgY2xlYW4gdGVzdGRsbC5kbGwgZm9yIGxhdGVyIHBlcnVz YWwiDQpvYmpkdW1wIC1hIC1mIC1wIC14IC1kIC1EIC1TIC1zIC1nIC1lIC1H IC10IC1UIC1yIC1SIHRlc3RkbGwuZGxsID4gdGVzdGRsbC5kbGwub2JqZHVt cA0KDQplY2hvICIjIyBSdW5uaW5nIHRlc3RtYWluLmV4ZSwgc2hvdWxkIHBy b2R1Y2UgYSBXaW5kb3dzIHBvcHVwIGVycm9yIGJveCINCmVjaG9kbyAiLi90 ZXN0bWFpbiINCg0K ---1463811071-1306756812-1076655404=:28458 Content-Type: text/plain; charset=us-ascii -- 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/ ---1463811071-1306756812-1076655404=:28458--