Date: Thu, 10 Mar 94 12:01:00 -0600
From: rcharif AT math DOT utexas DOT edu
Posted-Date: Thu, 10 Mar 94 12:01:00 -0600
To: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp
Cc: mcastle AT umr DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: GDB for GO32 and EMX
Reply-To: rcharif AT math DOT utexas DOT edu

Hi,

>  were looking for a debugger.  Also, it would be nice to nip the "why
>  doesn't somebody [else!] port GDB for us" thread at the spool.  So I
>  mentioned the multi-tasking in hopes of cooling their ardor.

Because it would be amazingly annoying. Try to look at gdb's source
code, it is amazingly ugly and full of hacks to make it work under
multiple platforms. (I am not criticizing gdb, I am criticizing the
non standard way each unix implements subprocess monitoring).

>  support GDB because it didn't support multi-tasking.  Again, this is
>  pretty vaporous.

You can add gdb to djgpp and you don't need muiltitasking, only one of
the process would be running, gdb or the user's process . go32 would
load the image of gdb in upper memory the same way it loads emu387,
then it passes controll to gbd. You will need to simulate the ptrace
system call as everything goes through it. The best trial
configuration would be to configure gdb for linux or bsd 386 and go
from there.

One problem in this approach is that gdb and the user process are
sharing the buffers that the pm application uses to communicate with
go32. Some work needs to be done so that a gdb gets linked with a
different library and uses different buffers, otherwise switching
tasks would involve lots of saving and the application might easily
corrupt gdb's buffers.

some time ago (long time), I did a test by cross compiling a gdb
configured for linux and linking with djgpp libraries. If memory
serves, I remember the following calls unresolved :
	- ptrace
	- tty calls for the readline library (readline compiles under go32
	  but it is buggy and doesn't work as expected)
	- job and process control
	- signal handling
	- fork (not needed as go32 will load the executable)
	- ...

Lots of patience and courage are also required in order to understand
the iner working of gdb in order to handle the special cases.

There is a porting guidelines and tips in gdb doc files (tex, info).

Building the system from Linux would be recommended over building from
dos, there is a lot of name clashes and gdb can be used to debug
itself on simulated go32 syscalls.

Regards,
Rami