From: "Barry Marks" Newsgroups: comp.os.msdos.djgpp References: <199904072135 DOT RAA23952 AT delorie DOT com> Subject: Re: Debugging Lines: 75 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: NNTP-Posting-Host: 204.2.11.4 X-Trace: news15.ispnews.com 924019090 204.2.11.4 (Tue, 13 Apr 1999 11:58:10 EDT) NNTP-Posting-Date: Tue, 13 Apr 1999 11:58:10 EDT Date: Tue, 13 Apr 1999 10:53:53 -0500 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com The first 2 can be done with either rhide or rhgdb, rhide's stand alone debugger. Barry John Drabik wrote in message <199904072135 DOT RAA23952 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 > >