Mail Archives: djgpp-workers/1999/06/07/09:27:52
On Mon, 7 Jun 1999 muller AT cerbere DOT u-strasbg DOT fr wrote:
> The dbgcom.c code traces the changes to the selector limits
> and if it knows that currently the ds selector has a limit of $0xfff
> then it knows that it is a fake exception !
> But the problem is that it cannot know which fake exception was generated !
Is it possible to set the DS limit to something that is slightly less
than 4KB? If so, we could set it to 4KB minus the fake exception number,
and then the debugger could know what signal was that by looking at the
selector limit.
Another possibility is to make the `forced' variable global. Then the
debugger could peek and poke it by reading/writing child's memory. Of
course, this would only work when debugging unstripped programs, but I
think it is good enough for starters. What do you think?
> The last solution is to intercept the real mode interrupts
> and to write special real mode interrupts that are only active when the
> child is running,
> and that will invalidate both GDB and the debuggee selectors so we know
> which real mode interruption was generated and thus translated it into
> the appropriate SIG number !
The problem is that the hardware interrupt, like Ctrl-C press, and the
exception it causes due to 4KB-limit of DS may be far apart in time, if
the child doesn't touch any PM memory for some time. If we trace the
interrupts themselves, we might have hard time to tell what signal to
generate.
- Raw text -