X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Date: Mon, 18 Feb 2002 21:21:53 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "MarKol" <markol4 AT wp DOT pl>
Message-Id: <968-Mon18Feb2002212153+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <a4rfgu$sbg$1@news.tpi.pl> (markol4@wp.pl)
Subject: Re: DS and ESP
References:  <a4rfgu$sbg$1 AT news DOT tpi DOT pl>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "MarKol" <markol4 AT wp DOT pl>
> Newsgroups: comp.os.msdos.djgpp
> Date: Mon, 18 Feb 2002 10:26:13 +0100
> 
>    +I wonder if gcc, doesn't change ds?

Code generated by GCC assumes DS = SS = ES.

>     I think that there no need to change to change ds for compiler but
>     I'm not sure about this.
>    +Are DJGPP's libc function conform to his rule?
>     In other words I wonder in there is some piece of code in DJGPP's libc
>     which may be executed during normal program flow (not loading
>     or ending),  and changes ds selector (and it is possible
>     to accept HW interrupt by CPU at ehis moment)?

DS may become invalid if a signal happens, like if you press Ctrl-C
or run with timers.  The library provides a special alias selector,
__djgpp_ds_alias, which is always valid and spans the same memory
region as the selector normally loaded into DS.

>  b) similar problem is about esp (I belive that ss is valid ).
>     My stub routine assumes that valid program data on stack are
>     pointed by esp and higher values.

The interrupt handler is called on a special locked stack provided by
the DPMI host.  Is this the stack you are talking about?  If so, it
will never clash with the application's stack.

>     Anything below esp is not
>     important for the program. But I've seen codes like this
>     (simple but ilustrates problem accessing stack segment below esp,
>      maybe programmer thought that nothing wrong can happen):
> 
>     mov   [esp-4],    eax
>     shl   eax,        cl
>     add   [edi],      eax
>     mov   eax,        [esp-4]
> 
>     If HW interrupt will be accepted between eax is restored there
>     are valid program data on the stack below esp. My asm stub uses
>     user stack below esp, and assumes there is no valid
>     user data below esp (it uses 8 bytes for ss and esp)

It is IMHO a very bad idea for the interrupt handler to use the
application stack.  Especially since the selector loaded into SS can
become invalid exactly like DS.