Mail Archives: djgpp-workers/1999/05/24/10:07:45
I rebuilt current CVS version of DJGPP and after that patched gdb-
4.18 with it (only my patches from which only one for go32-nat.c
can influence that).
It appears that I was wrong. The problem is with hardware assisted
breakpoints (hbreak). Other breakpoints (break, tbreak) seems to
work Ok. The worst is that we're unable to resume program
execution after it's getting SIGTRAP.
First expression is that translation from interrupt to exception
(src/libc/go32/exceptn.S) fails for SIGTRAP when running under
debugger. This is unfortunatelly rather tricky thing.
I tested earlier binaries I had:
5th Jaunary binary of gdb-4.17 (at that time there were rather
active work with dbgcom.c by Pierre and me). That binary
seems to get hardware breakpoint as required. Later updates
provided additional functionality but seems to have broken
something
ANdris
On 24 May 99, at 11:43, Eli Zaretskii wrote:
> I checked out the latest dbgcom.c and include/debug/dbgcom.h from CVS
> and built GDB with them. Unfortunately, the resulting binary doesn't
> work correctly. In the following fragment from go32-nat.c:
>
> {
> if (a_tss.tss_irqn == sig_map[i].go32_sig)
> {
> #if __DJGPP_MINOR__ < 3
> if ((status->value.sig = sig_map[i].gdb_sig) !=
> TARGET_SIGNAL_TRAP)
> status->kind = TARGET_WAITKIND_SIGNALLED;
> #else
> status->value.sig = sig_map[i].gdb_sig;
> status->kind = TARGET_WAITKIND_STOPPED;
> #endif
> break;
> }
> }
>
> if I enable the v2.03 part, breakpoints stop working (GDB says the
> program got SIGTRAP instead), and if I enable the v2.02 part, Ctrl-C
> kills the debuggee, like with the old dbgcom.c
>
> Is there anything else in the library I should update besides dbgcom.c
> and <debug/dbgcom.h>?
>
> > At least I have successfully debugged debugger part in rhide with itself
> > (with gdb-4.17 not 4.18, but I don't think it's a problem as such
> > possibility is determined by dbgcom.c)
>
> Maybe, if it's not much of a bother, you could send me your source of
> dbgcom.c and your libdbg.a, so I could verify that I didn't do
> anything stupid when I upgraded dbgcom.c?
>
> I'm mainly concerned that something has gone wrong when I checked
> dbgcom.c into CVS, and we will release a buggy libdbg.a with v2.03,
> after all the efforts that went into improving the debug support.
>
> > Also You should apply patch to gdb/go32-nat.c sent recently to this
> > mailing list.
>
> I did that, thanks (the fragment above is part of that patch).
>
- Raw text -