Mail Archives: djgpp/2000/12/19/06:22:50
On Mon, 18 Dec 2000, Tuukka Kalliokoski wrote:
> Here is the timer interrupt routine, that raises the SIGILL
> scheduling signal:
Thanks, but that doesn't give enough info.
First, please post a SYMIFY'ed traceback, both from Windows and from
plain DOS. If the traceback points into code that isn't included in
what you posted, please show that code as well.
See below for more missing info.
> And here is main part of the SIGILL handler:
This doesn't show where the control is returned to user code (I assume
that the SIGILL handler acts as a scheduler, so it must jump to
application's code at some point). It is important to see where it
does so.
> .align 4
> __lwpScheduler:
>
> movl $1, lwpInterruptPending
>
> movl ___djgpp_exception_state_ptr, %edi
> cmpl $0, %edi /* SIGILL was raise()'d, not by interrupt */
> je raised
> cmpl $0x99, 56(%edi) /* our exception or real exception? */
> jne raised
>
> movl 0(%edi), %eax
> pushl %eax
> movl 4(%edi), %ebx
> movl 8(%edi), %ecx
> movl 12(%edi), %edx
> movl 16(%edi), %esi
> movl 24(%edi), %ebp
>
> movl 28(%edi), %eax
> movl %eax, tmp1 /* esp */
> movl 32(%edi), %eax
> movl %eax, tmp2 /* eip */
> movl 36(%edi), %eax
> movl %eax, tmp3 /* eflags */
> movl 20(%edi), %eax /* edi */
Frankly, I don't understand why is there a need for all this
complicated stuff. In DJGPP, a signal handler is called in the normal
application's execution environment. This means DS, ES and SS are
already set up as C code expects them. So you can simply call the
user code (whatever thread needs to be run), without all the fiddling
with registers. The only thing you need to do is restore the thread's
registers and (possibly) to switch to a different stack.
So why is all this complexity here? It is quite possible that some of
it messes up the normal execution environment, which is already set up
for you.
> movl %eax, %edi
> popl %eax
> .byte 0x2e
> movl tmp1, %esp /* stack switched to exception state stack */
Here's one example: this switches to the exception stack, but where is
the code that switches back to the normal application stack?
I also don't see any code which saves the registers of the interrupted
thread and restores the registers of the thread about to be run.
Where is it?
> Here is the C fragment that vectors the IRQ and signal handlers:
>
> /* SIGILL is raised when an unhandled exception is raised */
> _lwpOldHandler = signal(SIGILL,_lwpScheduler);
> _lwpOldFpuHandler = signal(SIGFPE, _lwpFpuHandler);
> irq8.offset32 = (int)_lwpPmIrq8TimerHook;
> irq8.selector = _my_cs();
> __dpmi_get_protected_mode_interrupt_vector(IRQ8,&_lwpOldIrq8Handler);
> __dpmi_set_protected_mode_interrupt_vector(IRQ8, &irq8);
This doesn't show the code which locks the interrupt handler's code
and data. Is it there, anywhere? If so, let's see it.
I see that LWP also has something to say about the FPU exceptions.
Does the example which crashes actually use FP code? If so, it's
possible that the SIGFPE handler is also involved in this; you didn't
show it.
> I suspect that the registers are pushed to stack on incorrect order,
What registers? I don't see any registers being pushed in the code
you posted.
> or something is missing from SIGILL handler. I am quite sure that
> this code has worked with older gcc version.
If you become desperate and want to make sure old DJGPP versions
indeed work with LWP, you can always install an old djdevNNN.zip and
try compiling and linking with it. Personally, I don't think this has
anything to do with DJGPP versions, unless some code you omitted will
demonstrate otherwise.
Does the LWP docs say exactly on what platform(s) the DJGPP version was
tested to work?
- Raw text -