Mail Archives: djgpp-workers/1999/03/23/05:50:35
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 -