Mail Archives: djgpp-workers/1999/05/24/07:40:58
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
Of course. GDB gets TARGET_WAITKIND_SIGNALLED that is
command to kill debugee. We should have
TARGET_WAITKIND_STOPPED to avoid that.
About breakpoints:
They seems to work normally with my binary gdb-4.18.
> Is there anything else in the library I should update besides dbgcom.c
> and <debug/dbgcom.h>?
No.
> > 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.
>
As far as I remeber I'm using now version of libdbg.a I built from
CVS version without changes. But perhaps it's best to recheck.
Andris
- Raw text -