delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/03/23/05:50:35

Message-ID: <B0000080657@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: DJ Delorie <dj AT delorie DOT com>
Date: Tue, 23 Mar 1999 12:50:03 +0200
MIME-Version: 1.0
Subject: Re: Debugging support in DJGPP
CC: djgpp-workers AT delorie DOT com, Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
In-reply-to: <199903221512.KAA00706@envy.delorie.com>
References: <Pine DOT A41 DOT 4 DOT 05 DOT 9903221012410 DOT 32280-100000 AT ieva01 DOT lanet DOT lv> (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

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019