Date:	Wed, 1 Dec 1999 09:58:16 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Steve Goodrich <steveg AT cirris DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: Remote Debugging - dpmi exceptions
In-Reply-To:	<820u2k$jd7$1@news.aros.net>
Message-ID:	<Pine.SUN.3.91.991201095746.4575F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 30 Nov 1999, Steve Goodrich wrote:

> I am makeing the assumption that I should be registering these
> through the dpmi services. The problem is, when I make the call to
> register the new handler, it fails
> (__dpmi_set_extended_exception_handler_vector_pm returns a -1).

This is the wrong way: you cannot reliably use the function
__dpmi_set_extended_exception_handler_vector_pm, because it is only
supported by version 1.0 of the DPMI spec, and most DPMI servers out
there only support version 0.9.  So this call will almost always fail.

What you need is to modify i386-stub.c to use the special DJGPP debug
support functions (they are in the libdbg.a library), in the same
manner as go32-nat.c file in the GDB distribution does.  These
functions already have the code that you tried to write, which hooks
the debug and trap exceptions and longjmp's when a breakpoint is hit.
You just need to call these functions fvrom i386-stub.c.

If you want to look at the source for these functions, it is in
djlsr202.zip archive, in the src/debug/common directory.  The key
functions from libdbg.a that you need to study are `v2loadimage' and
`run_child'.

- Raw text -