* crash using _environ from libmsvcrt20/40.a
@ 2000-09-13 5:13 Nigel Wetten
2000-09-13 6:14 ` Chris Faylor
0 siblings, 1 reply; 6+ messages in thread
From: Nigel Wetten @ 2000-09-13 5:13 UTC (permalink / raw)
To: cygwin
Hello all,
I'm using cygwin 1.1.4, and I've run into trouble accessing _environ
from libmsvcrt40.a (or libmsvcrt20.a - I don't know what the difference
is).
The demonstration code is trivial:
=============================================
main.c:
extern char **_environ;
int main(void)
{
while (*_environ)
printf("%s\n", *_environ++);
return 0;
}
=============================================
Build command:
gcc main.c -lmsvcrt40 -Wl,-Map,link.map
=============================================
00401044 <_main>:
401044: 55 push %ebp
401045: 89 e5 mov %esp,%ebp
401047: 83 ec 08 sub $0x8,%esp
40104a: e8 99 00 00 00 call 4010e8 <___main>
40104f: 90 nop
401050: a1 88 10 40 00 mov 0x401088,%eax
401055: 83 38 00 cmpl $0x0,(%eax)
It's the cmpl that causes STATUS_ACCESS_VIOLATION.
eax=0x40c425ff
I'm just guessing, but it looks like the value loaded into eax isn't
correct. Changing eax to 0x4040c4 (the place in memory shifted over a
couple of bytes) makes the cmpl succeed. (but a similiar problem happens
at a subsequent instruction).
objdump says that 0x401088 is _environ:
00401088 <__environ>:
401088: ff 25 c4 40 40 00 jmp *0x4040c4
40108e: 90 nop
40108f: 90 nop
From the link map:
.text 0x00401088 0x8 /usr/lib/libmsvcrt40.a(ds00128.o)
0x00401088 _environ
.idata$5 0x004040c4 0x4 /usr/lib/libmsvcrt40.a(ds00128.o)
0x004040c4 _imp___environ
The real motivation here is that I was mixing msvc and gcc objects, with
references to _environ coming out of the msvc objects. I linked in
libmsvcrt40.a, but the program fails. Then I noticed that even reduced
to a single file it still fails using only the cygwin toolchain. Using
only msvc, this example program works however.
Any clues as to what's gone wrong and how it can be fixed? Has the
linker done something wrong, is the the code in the import libraries at
fault? Or do I need to use some different build flags?
Thanks.
Nigel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: crash using _environ from libmsvcrt20/40.a
2000-09-13 5:13 crash using _environ from libmsvcrt20/40.a Nigel Wetten
@ 2000-09-13 6:14 ` Chris Faylor
2000-09-13 7:27 ` Nigel Wetten
2000-09-14 3:03 ` David Starks-Browning
0 siblings, 2 replies; 6+ messages in thread
From: Chris Faylor @ 2000-09-13 6:14 UTC (permalink / raw)
To: cygwin
On Wed, Sep 13, 2000 at 01:12:21PM +0100, Nigel Wetten wrote:
>Hello all,
>
>I'm using cygwin 1.1.4, and I've run into trouble accessing _environ
>from libmsvcrt40.a (or libmsvcrt20.a - I don't know what the difference
>is).
MSVCRT*.DLL and Cygwin1.dll are mutually exclusive. You can't mix them.
If you want to use MSVCRT*.DLL use the -mno-cygwin option when you compile
and link.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: crash using _environ from libmsvcrt20/40.a
2000-09-13 6:14 ` Chris Faylor
@ 2000-09-13 7:27 ` Nigel Wetten
2000-09-14 7:14 ` Nigel Wetten
2000-09-14 3:03 ` David Starks-Browning
1 sibling, 1 reply; 6+ messages in thread
From: Nigel Wetten @ 2000-09-13 7:27 UTC (permalink / raw)
To: cygwin
> MSVCRT*.DLL and Cygwin1.dll are mutually exclusive. You can't mix them.
>
> If you want to use MSVCRT*.DLL use the -mno-cygwin option when you compile
> and link.
Thanks, I've added that, and objdump -p confirms that the binary does
not use cygwin.dll, BUT the program still faults in the same way.
To re-iterate, the instructions that try to load the address for
_environ are loading the first 4 bytes from:
(objdump -d -S a.exe)
00401298 <__environ>:
401298: ff 25 d0 30 40 00 jmp *0x4030d0
and using this value causes the access violation. If I manually change
it every time to 0x4030d0, the program can actually execute, although
_environ seems to point to garbage.
At this point, I'm just a bit confused about what's going on. I don't
understand why the 2 bytes for the jmp opcode are there, or
alternatively why the main progam code that tries to load the address
for _environ, accidentally gets 2 bytes of the opcode for jmp and
therefore faults.
The link.map suggests that the address 0x4030d0 is the right place:
.idata$5 0x004030d0 0x4 /usr/lib/libmsvcrt40.a(ds00128.o)
0x004030d0 _imp___environ
The progam works when compiled with msvc, which suggests to me either
there is a problem in the import library, or perhaps have I done the
build incorrectly?
Nigel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: crash using _environ from libmsvcrt20/40.a
2000-09-13 6:14 ` Chris Faylor
2000-09-13 7:27 ` Nigel Wetten
@ 2000-09-14 3:03 ` David Starks-Browning
1 sibling, 0 replies; 6+ messages in thread
From: David Starks-Browning @ 2000-09-14 3:03 UTC (permalink / raw)
To: cygwin
On Wednesday 13 Sep 00, Chris Faylor writes:
> MSVCRT*.DLL and Cygwin1.dll are mutually exclusive. You can't mix them.
I've added this to the FAQ.
David
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: crash using _environ from libmsvcrt20/40.a
2000-09-13 7:27 ` Nigel Wetten
@ 2000-09-14 7:14 ` Nigel Wetten
0 siblings, 0 replies; 6+ messages in thread
From: Nigel Wetten @ 2000-09-14 7:14 UTC (permalink / raw)
To: cygwin
> > MSVCRT*.DLL and Cygwin1.dll are mutually exclusive. You can't mix them.
> >
> > If you want to use MSVCRT*.DLL use the -mno-cygwin option when you compile
> > and link.
>
> Thanks, I've added that, and objdump -p confirms that the binary does
> not use cygwin.dll, BUT the program still faults in the same way.
For the benefit of anyone who's interested, and didn't already know:
extern __declspec(dllimport) char **_environ;
is what was needed.
I had tried using the msvc++ header for _environ(stdlib.h), but it
doesn't use
declspec, and I couldn't find any cygwin header that had _environ in it.
The object code generated for accessing _environ now has an extra layer
of
indirection in it. Unfortunately, my real motivation here is to link a
msvc object(I don't have the source) which needs _environ. The object
code in it does not have this extra layer of indirection in it. I'm not
sure whether I can use libmsvcrt.a in the link now.
Kudos to Benny Riefenstahl for clueing me in.
Nigel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: crash using _environ from libmsvcrt20/40.a
@ 2000-09-13 7:11 Chris Faylor
0 siblings, 0 replies; 6+ messages in thread
From: Chris Faylor @ 2000-09-13 7:11 UTC (permalink / raw)
To: cygwin
On Wed, Sep 13, 2000 at 01:12:21PM +0100, Nigel Wetten wrote:
>Hello all,
>
>I'm using cygwin 1.1.4, and I've run into trouble accessing _environ
>from libmsvcrt40.a (or libmsvcrt20.a - I don't know what the difference
>is).
MSVCRT*.DLL and Cygwin1.dll are mutually exclusive. You can't mix them.
If you want to use MSVCRT*.DLL use the -mno-cygwin option when you compile
and link.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-09-14 7:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-13 5:13 crash using _environ from libmsvcrt20/40.a Nigel Wetten
2000-09-13 6:14 ` Chris Faylor
2000-09-13 7:27 ` Nigel Wetten
2000-09-14 7:14 ` Nigel Wetten
2000-09-14 3:03 ` David Starks-Browning
2000-09-13 7:11 Chris Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).