Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E26A@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: G++ guru's please comment - Re: FW: pthread_create problem in
	 Cygwin 1.1.8-2]
Date: Mon, 9 Apr 2001 19:09:11 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Monday, April 09, 2001 4:47 PM
> To: cygwin AT cygwin DOT com
> Subject: Re: G++ guru's please comment - Re: FW: 
> pthread_create problem
> in Cygwin 1.1.8-2]
> 
> 
> On Mon, Apr 09, 2001 at 02:34:04PM +1000, Robert Collins wrote:
> >
> >> -----Original Message-----
> >> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> >> On Mon, Apr 09, 2001 at 11:31:57AM +1000, Robert Collins wrote:
> >> >> -----Original Message-----
> >> 
> >> I wouldn't expect the stack pointer to be screwed up.  I'd 
> expect that
> >> the *stack* is screwed up.  I don't believe that the ecx 
> >> register should
> >> be preserved across function calls so I don't know why this 
> >> would mater.
> >
> >Doh! Ask me how many years since I wrote assembly.... please :]
> >
> >Well, the exception occurs on the last line here (Intel 
> format cause I'm
> >reading intel doco).
> >
> >call   0x404c98 <sched_yield>
> >mov    %eax,DWORD PTR [%ebp-100]
> >add    %eax,4
> >mov    %edx,DWORD PTR [%eax]
> >mov    %ecx,DWORD PTR [%edx]
> >mov    DWORD PTR [%eax],%ecx
> >
> >As you can see, no stack references :[. And the crash 
> doesn't occur if
> >the thread doesn't lose the processor.
> 
> I'm confused by this snippet of assembly.  It looks like gcc is using
> the result of sched_yield to index into a table.  

Are you sure? IIRC my Intel backward-thinking-mindset "mov %eax,DWORD PTR
[%ebp-100]" moves the DWORD at address %ebp-100 (isn't that in the stack? I
don't remember), INTO %eax, thus completely discarding the return value from
sched_yield (most probably because it's not used by the source code), then
use this value read from %ebp-100 to load in %edx the field at offset 4 from
some data structure (NOT an array of pointers, it's lacking a multiply by
4), then use %edx as the address of another poiter that it copies back
replacing the first pointer (the one loaded in %edx).

If I'm still good at decompiling code, I'll say this is what would compile
to the following C code:

	struct queue {
		struct queue* next;
		struct queue* prev;
		...
	} * head;

	sched_yield();
	head->prev = head->prev->prev;

I would not be so surprised if the next ASM line would read like

	sub	%eax,4
	mov	DWORD PTR[%ecx],%eax

that is 

	head->prev->next = head;

Then some code may use %edx, that is the queue item removed from the end of
queue (probably due to the discussion this is the queue of active
try-blocks...).

> But, %eax should be
> either 0 or 1 in this case.  So, maybe you're right.  This is a gcc
> problem.  And, it may be fixed by configuring gcc with 
> --enable-threads.

Surely this may change something, but I don't think it's due to the code
snippet above; my best bet is that for some reason the queue of active
try-blocks is maintained as a global structure if threads are not enabled
while it should be maintained as a per-thread value if one want to use
threads (and one does it in sched_yield).

So I don't know if --enable-thread will solve the problem; what I positively
know is that using non-thread-aware code in a multi-threading program is a
sure call for problems.

> 
> This is one of those situations where it looks like gcc can't be
> released until a version of cygwin is released with the requisite
> functionality.

I don't understand: either cygwin support threading and gcc should be
compiled with --enable-thread, or cygwin do not support threads, and then
the program should not use them.

What seems to be the problem is that GCC thread-aware exception system is
not properly PORTED to cygwin (if it cannot be compiled using current cygwin
thread system). In this case one should either use gcc exception system OR
cygwin threading system untill the cygwin GCC port has been fixed :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple