Message-ID: <3698C3C5.D9B2FB3E@gmx.net>
Date: Sun, 10 Jan 1999 14:14:13 -0100
From: Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Organization: none provided
X-Mailer: Mozilla 4.07 [de] (Win95; I)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: debug GDB with itself
References: <B0000061324 AT stargate DOT astr DOT lu DOT lv>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Andris Pavenis wrote :
> 
> FSDB saves FPU state itself. gdb-4.17 (with unofficial patches for DJGPP from
> Robert) does the same in the same way as FSDB. So I think we should either
> modify both and do FPU saving in run_child() in the way it is done in FSDB or
> remove saving it from dbgcom.c at all. Otherwise all debuggers that saves

I would prefer to modify dbgcom.c to provide that feature. But please,
if you thing about sending a patch for it make the patch separate from
other features, which means, do not mix patches from the exception
problem (or others) and the new feature about saving/resoring the FPU
state. If you (or the others) want, I would do this patch (probably
by simply moving the code from the FSDB sources to dbgcom.c).

> My latest tests shows that there are more problems than I expected.

My tests too. :-( But since I don't have the knowlage about all
that exception stuff in DJGPP I cannot help here.

> So what can we do:
>         one way could be disabling hooking exceptions in debugee at all.
>         Possible problems:  we have to also forbid hooking some interrupts
>         including keyboard one. We still will be able to debug programs
>         that doesn't hook keyboard (except signal handling of course)
> 
>        Other way would be make stubs for all needed interrupts and exceptions
>         in dbgcom.c and call handlers set by program being debugged from these
>        stubs.
> 
> I would prefer the second way as first one is perhaps too restrictive.

I have also a third way: :-) Let the things as they are, since in
my opion the few request for such a feature do not compare to the
needed work for implementing it with the chance, that some current
behaviour will be broken and some(many) new bugs will be introduced.
But that's only my personal opinion.


Robert
-- 
******************************************************
* email:   Robert Hoehne <robert DOT hoehne AT gmx DOT net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************