Mail Archives: djgpp/2000/03/14/09:46:07
On Mon, 13 Mar 2000, Michael Tippach wrote:
> IIRC even FPU exception handling is done using the segment limit
> alteration kludge.
That's correct.
> A way that would also work under NT is to make the
> IRQ 13 handler just set the EM bit in CR0 by trying both, DPMI function
> 0xE01 and direct writes to CR0.
I'm not sure I understand what problem does this solve. Currently,
the EM bit is set by calling function 0E01h at startup.
> Under a CPL 0 host, conditionally setting the NE bit (just once
> at startup) allows for exception 16 instead of involving the interrupt
> controller.
This still doesn't solve the problem of converting an exception to a
signal. Signal handlers are (almost) normal C functions, so they
cannot be run from an exception handler. The issue at hand is how to
pull this conversion trick safely and portably, not how to generate
the exception.
Besides, CPL 0 host is not so interesting for DJGPP, which is mostly a
CPL 3 environment for writing ``normal'' application programs.
Writing low-level stuff like OS kernels is not something DJGPP is
meant to be well suited for.
> CTRL-C and friends are a bit trickier.
>
> One possibility would be to conditionally alter the CS limit instead,
> _IF_ the DPMI host is CPL0 OR NTVDM (should work with both).
Not good. CPL 0 and NT are among the least interesting DJGPP targets.
Futzing with the CS selector is among the most dangerous things in
general, AFAIK.
> OR,
> have the run time environment maintain SS as a mere alias to DS.
Will this work with the -fomit-frame-pointer switch to GCC?
In any case, if SS is a different selector, SIGINT won't be generated
until the program touches some *global* or static variable. Touching
an automatic variable won't produce SIGINT. Since global and static
variables are used much less than local ones, this might mean
deferring the signal much more than it is today.
> OR,
> one somewhat more memory intense, albeit pretty generic approach would
> be to let the interrupt handler make a copy of the code section
ALL of the code section? That might be megabytes to move inside an
interrupt handler, right?
Please note that this mechanism is also used by the timer interrupt
handler (to produce SIGPROF and SIGALRM), so it must be fast enough to
allow a program sustain an interrupt every 55 msec and still have
enough CPU cycles left to do something useful.
Moving the code also makes debug support next to impossible (if you
want to debug programs which install signal handlers).
- Raw text -