[fpc-pascal]Debuging in Freepascal

[Pierre Muller]

At 23:03 25/09/00 , vous avez écrit:


>Pierre Muller schrieb:
>
> >
> > This usually means that a real interrupt is redirected into protected code
> > by the program.
> > If this is a hardware interrupt, all code and data must be locked
> > and a special selector must be used instead on the usual one.
> > (see api/go32v2/mouse.inc for an example)
>
>I think you are right, it seems to be the serial part of the program. Without
>accessing the serial port the program doesn´t crash.
>
>I had a look into mouse.inc and it is a lot of assembler code and looks very
>difficult.
>Have i to lock every variable which are used in the interrupt function ?
>Maybe it is enough to lock the code of the isr and the data buffer where the
>transfered bytes are stored ?
>The registers are saved by the keyword interrupt ?
>
>
>Const Ktr: Byte = 0;  {These are STATIC variables so pascal doesn't }
>       IIR: Byte = 0;  {constantly have to redeclare them on the heap}
>
>
>Procedure COM_ISR; Interrupt;
>Begin
>    asm
>      cli
>      movw %cs:our_ds,%ax
>      movw %ax,%ds

This will not work correctly for at least two reasons :
1) our_ds is not locked !
2) our_ds selector's limit is put to $fff
each time a real time interrupt (like keyboard interrupt)
is triggered and needs to be reflected into a protected mode signal.
For example pressing Ctrl-C does this.

   Thus you should use
    movw %cs:v2prt0_ds_alias,%ax
But don't forget to also lock this address

   lock_data(v2prt0_ds_alias,sizeof(longint));

mouse.inc uses the entry value of the es register which is
the value given for the structure that contains the real mode registers
at entry of the protected mode function called by the Real Mode CallBack.

You should read carefully the DPMI specification of the RMCB function
(in Ralph Brown interrupt list for instance)