Message-Id:	<199904072135.RAA23952@delorie.com>
From:	"John Drabik" <jdrabik AT caldera DOT com>
To:	"salvador AT inti DOT gov DOT ar" <salvador AT inti DOT gov DOT ar>,
	"conductors AT canvaslink DOT com" <conductors AT canvaslink DOT com>,
	"tibors AT opera DOT iinet DOT net DOT au" <tibors AT opera DOT iinet DOT net DOT au>,
	"eliz AT is DOT elta DOT co DOT il" <eliz AT is DOT elta DOT co DOT il>,
	"djgpp AT delorie DOT com" <djgpp AT delorie DOT com>
Date:	Wed, 07 Apr 99 15:29:54 +0600
X-Mailer:	Automated Warehousing's Registered PMMail 1.53 For OS/2
MIME-Version:	1.0
Subject:	Debugging
Reply-To:	djgpp AT delorie DOT com

Hello,
	I hope you don't mind that I've contacted you directly,
concerning some of the same debugging problems that have been noted in
the djgpp discussion lists.  I am not sure who may be best equipped to
answer these questions, or offer alternatives.  However, if an
acceptable debugging alternative can be defined, it is probable that
the company that I work for, Caldera Thin Clients, would pay to
implement the required changes, AND would allow the code to be put into
the public domain too.

	Here are some of the problems facing us: not all of them have
to be addressed at once, but at least the first two points must be
covered:

	1) Graphic app debug (i.e., graphical app, switch the debugger
to text mode), using Allegro
	2) Source-level debug (C, C++, and Asm).
	3) Mixed-mode (16-bit and 32-bit) debug support if possible. 
The 16-bit code is in Borland 3.1.  Two issues:
		A) using Borland Symbol and Map files with GDB
		B) supporting 16-bit apps (background TSRs mostly, but
also some 3rd party libraries)
	4) Remote debug, or debug redirection to a monochrome monitor,
is highly desirable.
	5) A separate "monitor" for debugging embedded systems, is also
desireable.

	We looked at Rawhide (it can't remotely debug, and Rawhide is
unable to load this rather large (1.5 MB without debug info, 4 MB with
debug info) application.  It also appears to have problems with
monochrome redirection, and it is unlikely that it might (eventually)
help with the Borland problem.  A 16-bit code generator for DJGPP would
be helpful here, and we could then drop Borland (perhaps - it depends
on 3rd party tools such as SSL secure sockets, LWPSOCK TCP/IP, and
others).  We'd be willing to work with Rawhide developers, also
probably "for hire" with the results going to the public domain, but as
they seem to rely on DJGPP anyway, why not start here first?

	I have successfully run Turbo Debugger and TDRemote on the
application, but it doesn't provide source-level support for GCC (and
the -S output of GCC doesn't intersperse the C source code, so it is of
very limited value).  We have looked at some other 3rd-party debuggers
too, but none of them come close to the combined source-level,
mixed-mode, large-app, and graphic-mode requirements of our projects.

	Reviewing the mail archives, it appears that debug support is a
common, and significant, problem for all DJGPP programmers, especially
remote debugging and graphical apps.  Our additional problems of
mixed-mode and mixed-tool environment exacerbate the situation. 
However, we feel that some improvement in the DJGPP debugging situation
would benefit many programmers besides ourselves.

	If you are interested in pursuing this work, or if you know of
a solution to the problems I've mentioned, please contact me so that we
can setup a phone conversation or further e-mails.  If you are not
interested, or if you feel that you are not knowledgeable enough to
contribute to the solution, please let me know and I will remove your
name from this list.  If you know of other programmers who might be
interested, please let me know that too.

	Thank you for any help you can provide.

Sincerely,
John Drabik
Caldera Thin Clients

- Raw text -