This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: i386-stub.c patch, remove exceptionHook cruft.
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: i386-stub.c patch, remove exceptionHook cruft.
- From: jtc@redback.com (J.T. Conklin)
- Date: 08 Sep 1999 11:21:05 -0700
- Cc: gdb-patches@sourceware.cygnus.com
- References: <199909080205.TAA09920@andros.cygnus.com>
- Reply-To: jtc@redback.com
>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> Unlike the previous patch, this gives me a slight pang of "well,
Stan> can't we just finish implementing it?". But someone will
Stan> probably have to do it from scratch anyway, the old code more
Stan> likely to be misleading than helpful, so out it comes.
The ExceptionHook in the m68k-stub is intended to provide a mechanism
for chaining exceptions. For example, when a exception is raised the
stub's exception handler (handle_exception) would get control first.
When the user steps or continues, the original exception handler is
called.
Although this can be a useful feature, IHMO a stub shouldn't impose
it's own model of exception handling on a target. I've used targets
with all sorts of different exception mechanisms. It is convenient
that the sample stubs come with code that saves an exception frame,
calls handle_exception(), and restores processor state; but it should
should not be unnecessarily difficult to remove/replace all that with
code specific to the target.
After examining the m68k stub a bit more, I believe that all the code
that attempts to find the corresponding exception frame on the stack,
etc. probably belongs in _returnFromException() so that the exception
handler itself is fairly generic.
But that's a bit more than I want to tackle at the moment.
--jtc
--
J.T. Conklin
RedBack Networks