Mail Archives: cygwin/2004/02/13/02:02:42
---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 <doctor AT fruitbat DOT org> or <Peter DOT Castro AT oracle DOT com>
"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: <Pine DOT LNX DOT 4 DOT 53 DOT 0402122256440 DOT 28458 AT gremlin DOT fruitbat DOT org>
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--
- Raw text -