Debugging an embedded(?) system

[Coldfire]

Hi

A friend is developing, from many years, a sort of Operating system, for X86, protected mode. Is written completely in Pascal, however, with time, debugging and developing this is getting harder. Originally debugging was made using turbo pascal's remote debugging capabilities using a serial port(like watcom's debugger). However, this stopped to work when he decided to make this system run in 32bit protected mode. So he, in the late 90's migrated this project to virtual pascal to compile and debugging, running all in windows 98. however the process turned into a mess because it can't debug the operating system directly.

So, What's the question? Is there a way of remote debug remotely a frepascal program using ethernet or serial port to an "empty" system?

[Leledumbo]

If it's an x86 based OS, you can always use Qemu / Bochs, both provides extensive debugging capability. Both can provide a port for GDB to connect and debug like a normal program.

[marcov]

So, What's the question? Is there a way of remote debug remotely a frepascal program using ethernet or serial port to an "empty" system?

Free Pascal uses GDB, but that requires a suitable gdb build on your target. So if you can qemu handle that side, as Leledumbo says that sounds like the best way to go for an homebrewn OS.

[Coldfire]

Coming back!

well, i have read a lot during this time, and I somewhat-know what I need. The i386 stub for gbd is written in C, i need to link it along with my code and i need to provide to the C written stub, the following functions:

-int getDebugChar()

-void putDebugChar(int)

so i need some guidance, i don't know if i really need that C written stub(can I write my own in Assembly or Pascal?). I'm writing now the interrupt-based-serial-driver in NASM assembly to provide those functions later, but i don't know what calling convention FPC generated code uses. Also i don't know if freepascal uses the C underscore for calls. Also i need to link C and pascal code in the same "executable", what i need to know when I do things like that?

Also, i have some problems when writing the interrupt routine. Now i have something like this...
....
   proc far int_16550
   pusha
   
   ;intID

   mov dx, ioIIR+iobase
   in ax, dx

   cmp ax, INTYPE1
   je int_type_1
   cmp ax, INTYPE2
   je int_type_2
   cmp ax, INTYPE3
   je int_type_3
   cmp ax, INTYPE4
   je int_type_4
falsa_alarma:   
        mov al, 020h
        out 020h, al
   popa
   iret
INTYPE1:
   mov ax, seg buffer
   mov bx, buffer
   mov es, ax
   mov di, bx
   mov cx, INT_TRIGGER_LEVEL
   rep insb

   mov al, 020h
        out 020h, al
   popa
   iret
....

however, GDB says that i need to check a control-C received at UART interrupt. searching for a control-C can be made in buffer, or must be done when i take data from FIFO?

[marcov]

i don't know if i really need that C written stub(can I write my own in Assembly or Pascal?).

Usually you can write you own in Pascal. Probably always in assembler (compile the C to assembler to
get an idea)  Depends on the C compiler.

Note that your code seems 16-bit while you talk about a i386 (32-bit) GDB stub. What is your code, 32-bit or 16-bit? What FPC compiler do you use as basis, 16 or 32-bit?

Also i don't know if freepascal uses the C underscore for calls.

The underscore prefix depends on the target binary format, COFF mostly has it, ELF not. In case of doubt check the generated assembler (-al)

but i don't know what calling convention FPC generated code uses.

Register, something akin to fastcall. But you can specify cdecl; or stdcall; if you wish.

Also i need to link C and pascal code in the same "executable", what i need to know when I do things like that?

Satisfy all requirements. Hard to say, nearly everything is OS dependent.

Also, i have some problems when writing the interrupt routine. Now i have something like this...

The 16-bit segment handling (mov ax, seg buffer;mov es,ax )sounds flaky in combination with a 32-bits debugger. I never tried to debug 16-bit code with gdb.

[Coldfire]

thanks marcov!

well, I  will test the serial driver in DOS first, so code at the moment is 16bit, real mode, for NASM Then, if works(receives characters, and classifies and handles INT's properly) i will adapt it. I just need to know if "\003" (control-c) must be checked directly from FIFO, or can be checked in a sort of buffer, or for tasks like this, FIFO it's not suitable, and a "one char-one interrupt" approach for serial driver could be better.

at the moment, we want to generate the executable(the OS in fact) in plain format, our "os" has not any sort of symbol-related structure. it's just an editor, file handling, and interpreter.

the i386-stub included in GDB is written for GCC, so i will have to check how public calls are declared in the assembly code generated.