Mail Archives: djgpp/1998/08/31/05:03:44
On Sun, 30 Aug 1998, Ignacio =?iso-8859-1?Q?Garc=EDa?= =?iso-8859-1?Q?_P=E9rez?= wrote:
> Notice that when _my_ds() is called in the main program, sure I'll get the
> DJGPP correct DS selector, and then, I embed it into a constant in the code.
The selector is correct, but there are periods in your program's life
(see below) when DS is intentionally invalidated. If the timer tick
happens during these periods, your program will crash.
> This should make the interrupt procedure load the right DS selector at any
> time ***unless*** the DJGPP selector varies along the program execution. Is
> this possible ?...
Yes, it is possible: that's how signals work in DJGPP.
When you press Ctrl-C (which is supposed to generate the SIGINT
signal), that keypress is caught by the keyboard handler installed by
the DJGPP startup code. The handler processes Ctrl-C by making the DS
limit be 4K. Since all data in your program lives above the first 4K
(that's how things are set up at startup), the first time your program
touches any of its data, a CPU exception is generated, because
protected mode doesn't allow accesses to data beyond the DS limit.
This exception is caught by the DJGPP exception handler, which sees
that the exception was generated on behalf of a Ctrl-C, restores the
DS limit to its normal value, then calls "raise(SIGINT);".
The reason for this complexity is that you could press Ctrl-C while
the CPU was in real mode, like when your program calls DOS or BIOS.
The signal processing described above makes sure that the signal isn't
delivered to your program until the CPU is once again in protected
mode and in the normal foreground thread (because only then can it
touch any of its data). In particular, since the default action of
Ctrl-C is to abort the program, this ensures that the program can
*never* be aborted while the CPU is in real mode (the DPMI spec
forbids that).
The above description doesn't pertain to Ctrl-C alone. All the
signals supported in DJGPP that are generated by hardware interrupts,
like SIGALRM generated by the timer tick, work that way.
The upshot of all that is that if the timer ticks during a period when
DS is invalid (because some signal is pending), your handler will
crash if it uses DS. Using __djgpp_ds_alias solves this, since that
selector has the same base and limit as DS, but is *always* valid.
> (and thus necessary to load it every time from __djgpp_ds_alias).
No, you just need to patch your wrapper with the alias selector once.
There should be no need to reload it.
- Raw text -