Mail Archives: djgpp/2000/03/16/09:12:11
Eli Zaretskii wrote:
>
> On Wed, 15 Mar 2000, Michael Tippach wrote:
>
> > > Not before it does quite a bit of trickery to get things to their
> > > normal state again.
> >
> > Cleaning up the artificial condition created to trigger the exception is
> > not what I call trickery but a necessary step.
>
> ``Necessary'' does not contradict ``tricky''. I said ``tricky'' because
> the code isn't easy to get right. Clearly, a vanilla C code cannot run
> from the exception handler before it restores the normal execution
> environment. So generating an exception is only half of the job,
> albeit an important half.
It is this half of the job where one is either moving outside of what is
covered by the spec or putting up with a compromise that still might not
always work.
Vanilla C code does not have to run from an exception handler, but we
can (within the spec) make an exception handler return to whatever piece
of vanilla C code we want to execute next.
>
> > > For fake exceptions triggered
> > > by deliberately lowering the DS limit, this is easily done, since we
> > > lowered the limit ourselves. For real exceptions, it's not so easy.
> >
> > That is true. Though I fail to see the relevance for this as we were
> > always talking about deliberately causing exceptions in either case.
>
> The relevance is that checking the limit against 4KB is much easier than
> to look at all the other possible causes of real exceptions.
You do not have to look. If an IRQ- style signal occurs, the IRQ handler
ideally would set a global variable associated to the signal and do
whatever it takes to generate ANY kind of exception as soon as possible.
It does not matter WHAT kind of exception as long as the exception
handler in question is checking for an unhandled signal and, for each
one detected, resetting whatever had been done to generate an exception
(not necessarily this one) and resetting that global variable that
indicated the signal.
Now, processing the signal would either end up in continuation of main
line code execution, in which case the exception would just happen again
if it was for a different reason, or (more likely) there would be a
branch in main line code execution in which case the exception, even if
it was for a different reason, would not be re-triggered. And this is
absolutely correct since the instruction which faulted after the signal
has occured should not have been executed at all in the first place.
Bottom line: It does not matter WHY you get an exception after a signal
condition occured, it is only important THAT you get ANY kind of
exception ASAP.
>
> > Personally, I don't use DJGPP for I find the non- flat
> > memory model a bit offensive.
>
> I rather find it defensive (pun intended). It saves many a hacker from
> him/herself.
Personal taste cannot be argued about.
>
> > > > it takes 3 more lines of assembly code to detect NT.
> > >
> > > That's not really true, especially now that you need to distinguish
> > > between NT and W2K.
> >
> > So does W2K return a different value than 0x3205 from function 0x3306?
>
> No, it reports the same value, but behaves differently.
In how far does it behave differently? Could this different behaviour be
used to detect either version or is there no way to, by means of code,
inspect the differences without crashing the NTVDM on one system?
>
> > Well, make it 5 lines of code instead of 3, in that case.
>
> Please show us those 5 lines. It will help DJGPP tremendously, since
> currently I cannot find any way of telling NT from W2K.
The statement above was a conditional one ("in that case"). Regardless
of the answer to my question above, I would propose the following:
For FPU exceptions:
- Use the EM bit method in all environments. This method simply is more
accurate
Other IRQ-ish signals:
- When in ring 3 and NOT under NT or Win2K, keep existing system
- When in ring 0 use CS limit alteration
(more accurate than currently AND makes it work)
- When running under NT (any kind), use alias of DS in SS
(less accurate than currently BUT makes it work)
Regards,
Michael Tippach
- Raw text -