Message-ID: From: "Andris Pavenis" To: Eli Zaretskii , Robert Hoehne Date: Wed, 24 Mar 1999 16:20:35 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Debugging support in DJGPP CC: djgpp-workers AT delorie DOT com In-reply-to: <199903240649.BAA10763@mescaline.gnu.org> References: (pavenis AT lanet DOT lv) X-mailer: Pegasus Mail for Win32 (v3.02b14) Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Some summary about my tests with updated dbgcom.c I tested FSDB, gdb-4.17, slightly patched rhide-1.4.7. Results does not depend from program I'm using: SIGINT: I'm able to interrupt program with Ctrl-C or Ctrl-Break and resuming execution. No related problems found with this update. More strong torture were debugging debugging support in RHIDE with RHGDB. I even tried to interrupt program running under RHIDE with Ctrl-C and when I pressed it first time I got to RHIDE and when I immediatelly pressed it second time I interrupted RHIDE and entered top level RHGDB. SIGSEGV: No visible problems SIGFPE: there are some problems. I don't know why but debugger does not get SIGFPE when I'm stepping program ('next', 'step') but only when I'm running it. Anyway there is no crashes so I think it is not too bad problem Programs that hooks keyboard interrupt: I tried examples/ex5.c from Allegro examples which installs allegro keyboard handler. If I'm running it under old debugger (without modified dbgcom.c) allegro does not get keyboard input at all, but I can interrupt it. With modified dbgcom.c I'm getting keyboard input in Allegro so I can step program that reads keyboard in Allegro but debugger is not getting SIGINT (happens only if keyboard handler in debugee does not chain to old handler) So some summary: There are still some relatively small problems with exceptions. But anyway I think they are not so serious. I think that new available features are more significant. On 24 Mar 99, at 1:49, Eli Zaretskii wrote: > From: "Andris Pavenis" > > So I don't see serious problems that would prevent us from using it. > > If you think this will be safe, I don't have any objections. It would > be nice, though, if somebody would build GDB 4.16 with the modified > dbgcom.c and make sure it works. > Maybe it would be time to change to gdb-4.17 finally. Of course one can build gdb-4.16 once more. Is somebody going to build official binaries (or we are waiting for gdb-4.18 ...)? > > As result debugee does not get full command line (it is errorously truncated). It > caused problems for me when I tried to debug cpp.exe and cc1plus.exe. It doesn't > happen when I'm running rhgdb dumparg.exe .... from bash command line or bat > file. I don't know why it happens, but it is not a regression against previous > versions. It seems to happen only when bash is reading input from not from > terminal. > > If this is a setback relative to prior versions, it would be a good > idea to try to fix it. It doesn't seem as something really > complicated. Even if it cannot be solved easily, it would be nice to > know why does that happen. > Tested it's so also with RHGDB-1.4 (v2apps/rhide14b.zip) that is built before I even tried to mess with debugging for DJGPP at all more than a year ago. So it's not a new problem. It would be nice to fix it of course but as I said before I don't know why it happens. It seems to be a bug somwhere in libc.a. I think that transfering command line arguments to debugee is one of the things that should be reworked. But perhaps it should wait after 2.03 will be released (unless that is simple bug we can easy fix) Andris