This is the mail archive of the cygwin@cygwin.com 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]

Re: G++ guru's please comment - Re: FW: pthread_create problem in Cygwin 1.1.8-2]


On Mon, Apr 09, 2001 at 07:09:11PM +0200, Bernard Dautrevaux wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf@redhat.com]
>> Sent: Monday, April 09, 2001 4:47 PM
>> To: cygwin@cygwin.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@redhat.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).

Here is a standard prologue generated by gcc when compiling for an Intel
target.

        pushl   %ebp
        movl    %esp, %ebp

This moves the contents of the esp (stack) register into the ebp (frame pointer)
register.  The "movement" is left to right in gas syntax.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]