Mail Archives: djgpp/2002/02/18/14:26:15
> 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.
- Raw text -