Message-ID:	<B0000080709@stargate.astr.lu.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT gnu DOT org>, djgpp-workers AT delorie DOT com
Date:	Tue, 23 Mar 1999 15:31:44 +0200
MIME-Version:	1.0
Subject:	Re: Debugging support in DJGPP
In-reply-to:	<199903231227.HAA22322@mescaline.gnu.org>
References:	<B0000080657 AT stargate DOT astr DOT lu DOT lv> (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

On 23 Mar 99, at 7:27, Eli Zaretskii wrote:

>    From: "Andris Pavenis" <pavenis AT lanet DOT lv>
> 
>    Anyway I think dbgcom.c is a different thing. Perhaps we should carefully test
>    all available debuggers (FSDB, EDEBUG, GDB, RHIDE) with modified version and
>    if there is no serious problems we should go ahead instead of leaving this for 
>    some more far future.
> 
> One of the things I wanted to ask all those who ported some package
> was to rebuild the binaries with v2.03 as soon as it is released.
> (IMHO it is not right to have binaries compiled with old libraries.)
> How does this affect your recommendation about including dbgcom.c
> changes?
> 

There is not so much packages that depends on dbgcom.c (perhaps only
djdev+djlsr, gdb, rhide). FSDB seems to be Ok with my todays build of
DJGPP. I rebuild also gdb-4.17 (not official port of course as there is no such), but 
I haven't tested it yet. Perhaps I'll rebuild rhide and test it as I'm mostly using it.
So I don't think we should expect serious problems with update of dbgcom.c.

I'm using debuggers built with this version of dbgcom already for about 2 months 
and last change was fix of bug that prevented debugee to get return code from 
spawned process. I haven't touched exceptions related stuff in dbgcom.c for 
about 2 months and it works stable for me.

So I don't see serious problems that would prevent us from using it.

There is one problem I have found with debuggers but it seems not be regression
of suggested version against previous ones as I reproduced it using 
rhgdb-1.4.5 build almost year ago with DJGPP-2.01 (long before touching 
dbgcom.c):

	1) make simple program that dumps command line arguments and build it
	2) run it under rhgdb or other debugger from bash script with specifying long
              command line. For example:
		   #! /bin/sh
		   rhgdb dumparg.exe 11111111 22222222222 333333333 4444444444 
55555555 6666666 777777777 8888888

	    sh test.sh
           
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.

Andris

- Raw text -