libmigdb/DJGPP.why

   1 DJGPP Problems and why it isn't currently supported:
   2
   3  Traditionaly djgpp never used gdb frontends. The reason is not so obvious.
   4 The main problem is that DOS isn't a multitasking OS. So you can't open a
   5 pipe to a child a process and multitask. The pipe command exists but you are
   6 blocked until the child finishes.
   7 For this reason there is no gdb frontend for djgpp. Instead djgpp users use
   8 full debuggers with a frontend included. That's the case of RHIDE (in this
   9 particular case gdb is inside RHIDE).
  10  But most people using djgpp uses a multitasking OS, at least for development.
  11 The most common setup is Windows. Additionally you could use two DOS boxes
  12 and get real-hardware-multitask ;-)
  13  The two possible setups are:
  14
  15 1) Windows (win32): The frontend communicates with gdb using some IPC
  16 mechanism. The frontend uses the "start" (or similar) command to call gdb and
  17 then sends/receives the commands/responses using the IPC mechanism.
  18 Here Windows does the multitasking.
  19 That's completly transparent in most cases because the frontend starts gdb
  20 indicating which file to debug and the same front end controls gdb (including
  21 the end of sesssion).
  22
  23 2) Two DOS boxes: The user must run gdb in one of the boxes indicating to
  24 connect to the other using some networking protocol. On the other side the
  25 frontend is started and waits for a incoming connection.
  26 This is a little bit more complicated because:
  27 a) The user must setup a network.
  28 b) The user must start things manually.
  29
  30  But there are some problems that doesn't allow it:
  31
  32 GDB side:
  33
  34  GDB remote debugging isn't like this. It was designed for remote debug
  35 using multitasking systems and not things like DOS. When you use the remote
  36 debugging you run "gdbserver" on the "target" end and "gdb" on the local side
  37 (host). But then you are again in the same situation, you can't control gdb
  38 using pipes or similar mechanisms.
  39
  40  The solution for this is to tell gdb "Hey! use IPC for your command loop".
  41 But the problem is that gdb is a mess. It have a very nice abstraction for
  42 I/O implemented like classes (see ui-file.c). So you have gdb_stdout and
  43 gdb_stdin structures. But not all the code uses it, in fact the "readline"
  44 part (gdb prompt and input) bypass it.
  45
  46  To solve this you have to redirect at low level. Something like:
  47
  48 a) Open a socket.
  49 b) dup2 stdin/stdout
  50
  51  This is the easy part because you have to avoid this redirection in the
  52 child or the output of the debuggy will also go throu the IPC channel. But I
  53 think it isn't that hard because gdb switches the stdout/in attributes when
  54 running the child process, so I think it is possible to also dup2 to the old
  55 handles while the child is running.
  56
  57   In any case all of this means changes in gdb.
  58
  59
  60
  61 DJGPP side:
  62
  63  The "open socket and dup2" above mentioned mechanism works for POSIX systems
  64 like Linux (I tested it and worked, I was able to control gdb using TCP/IP
  65 sockets). But djgpp isn't POSIX.
  66
  67  DJGPP have a nice mechanism to for "File System Extensions", but when I
  68 tried it I found that dup2 doesn't work for extensions. I'm not sure if it
  69 can be done with some hack or if the last version of djgpp version solves
  70 this problem.
  71
  72  It most probably means that djgpp have to be modified. May be I'm wrong.
  73
  74
  75
  76 IPC what?
  77
  78  Inter-Process Communication is quite simple on POSIX systems but for djgpp
  79 ... Well, you can use a networking protocol, but again isn't that simple.
  80  For TCP/IP you have:
  81
  82 a) libsocket, it looks like it doesn't work very well with VSOCK 2. I tried
  83 it on Windows 98 SE and it failed.
  84 b) Watt-32, it needs a special NDIS driver for Windows.
  85
  86  Another option could be using mslot library. It seems to work (at least for
  87 Windows). It uses the "Mail Slot" mechanism. One problem I found in this
  88 library is that it implements the "read" FSEXT in a "non-blocking" way and
  89 doesn't honor the O_NONBLOCKING flag. The changes to fix it are really
  90 simple. According to mslot docs they are available for plain DOS.
  91
  92
  93 Conclusion:
  94
  95  It looks like is possible to achieve the above mentioned setups. But changes
  96 have to be made to gdb, djgpp and existing IPC libraries.
  97  The gdb part seems to be the most complex and harder to be introduced in
  98 main gdb.
  99
 100
 101 SET