Message-ID: From: "Andris Pavenis" To: DJ Delorie Date: Tue, 23 Mar 1999 12:50:03 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Debugging support in DJGPP CC: djgpp-workers AT delorie DOT com, Pierre Muller In-reply-to: <199903221512.KAA00706@envy.delorie.com> References: (message from Andris Pavenis on Mon, 22 Mar 1999 10:29:38 +0200 (WET)) X-mailer: Pegasus Mail for Win32 (v3.02b14) Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 22 Mar 99, at 10:12, DJ Delorie wrote: > > > Some time ago there were some efforts to add exceptions hooking support > > in dbgcom.c (Pierre Muller, I, Robert). At least seems that latest version > > is working Ok (You can test it with rhide binaries from my homepage: > > http://www.lanet.lv/~pavenis/rhide.html). I didn't find serious problems > > there. > > > > Only problem is with sources: there are so serious changes that diffs > > are bigger that original source. Even worse there are changes that are > > only editional (renamed assembler labels, etc). > > > > I think it would be nice to have support of there features in DJGPP-2.03. > > However latest version I have seems to still have some unneeded code > > (see http://www.lanet.lv/~pavenis/dbgcom.c) We'll I forgot to put also dbgcom.h there. Pierre added also some additional fields to structure NPX to support MMX as far as I understand. I removed RCS related fields and added also dbgcom.h. (see http://www.lanet.lv/~pavenis/dbgcom.zip) > > Eli and I talked about this, and we think it needs more testing. 2.03 > is supposed to be a bugfix-only release; we don't want to risk adding > more bugs. If you can convince djgpp-workers that it's tested enough > to warrant the risk, we can talk about it then. > > I'm not saying it *has* bugs, I'm saying we don't know, and I'd rather > *know* it doesn't have bugs than *guess* it doesn't have bugs. > Some thoughts about this topic. I think dbgcom.c is not the stuff most DJGPP users are using directly in their programs. About such commonly used functions as open(), fopen(), malloc() and many others I completely agree: we should avoid any changes that are not very carefully tested by many users. Anyway I think dbgcom.c is a different thing. Perhaps we should carefully test all available debuggers (FSDB, EDEBUG, GDB, RHIDE) with modified version and if there is no serious problems we should go ahead instead of leaving this for some more far future. Of course if the release is planed after a week there may be not enough time for testing. Even if we'll have some problems this will mostly not be serious problem for ordinary DJGPP users. Developers will be able to discuss possible problems here or solve them themselves. Also current version of dbgcom.c also contains bugs, not only missing features. It's simply to confirm that. Run program that spawns other DJGPP program under debugger and see what return code You'll getting when child wants to return non zero return code (source: register corruption in int 0x31 hooking code in dbgcom.c; fixed in version from my homepage) Today I upgraded to CVS version with replaced dbgcom.c and dbgcom.h files. I'll try to check debuggers later. So unless I'll find serious problems I would like to suggest to include these files. Andris