From: muller AT cerbere DOT u-strasbg DOT fr
Message-Id: <3.0.6.32.20000227151700.008625c0@ics.u-strasbg.fr>
X-Sender: muller AT ics DOT u-strasbg DOT fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Sun, 27 Feb 2000 15:17:00 +0100
To: djgpp-workers AT delorie DOT com
Subject: Re: Bug in  crt0.S
In-Reply-To: <200002211726.TAA10841@is.elta.co.il>
References: <200002171707 DOT SAA16280 AT cerbere DOT u-strasbg DOT fr>
 <200002171707 DOT SAA16280 AT cerbere DOT u-strasbg DOT fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

At 19:26 21/02/00 +0200, Eli wrote:
>
>>   I include here a diff to version 2.03 of crt0.S file that also fixes the
>> problem for the C library!
>
>Pierre, I don't understand this patch: it seems that you store
>something in sbrk16_interrupt_state, but never use that value:
>
>> *** 552,557 ****
>> --- 567,576 ----
>>   	movw	___djgpp_base_address+2, %cx
>>   	int	$0x31
>>   
>> +    /* Now we can reenable interrupts  PM */
>> +    movl  %eax,sbrk16_interrupt_state
>> +    int   $0x31
>> +    
>
>Shouldn't this be the other way around: "movl sbrk16_interrupt_state,%eax"?

Of course it should !! I am sometimes still interverting Intel and ATT
syntax :(

  In the original code its done just by pushing it 
on the stack and popping it back into %eax before calling int $0x31
again, as it is now postponed to later, I needed a variable to store the
return value of function 0x902.

  To Charles Sandmann, about the problem of locking :

  shouldn't the DPMI server copy the current lock flag for each page
that is move by the UNIXY SBRK function ?

 In that case, the only think would be to ensure that no sbrk call is made
inside the lock_data and lock_code functions, no ?