Date: Wed, 22 Sep 1999 07:40:31 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: pavenis AT lanet DOT lv
cc: djgpp-workers AT delorie DOT com, Morten Welinder <terra AT diku DOT dk>,
        DJ Delorie <dj AT delorie DOT com>
Subject: Re: FSDB broken in CVS version?
In-Reply-To: <B0000102676@stargate.astr.lu.lv>
Message-ID: <Pine.SUN.3.91.990922072614.26980A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Tue, 21 Sep 1999 pavenis AT lanet DOT lv wrote:

> > Seems that FSDB is broken in current CVS version of DJGPP (I haven't 
> > used FSDB much in last time, so didn't notice it earlier):
> > 
> > 	stepping over call instruction does not work as debugger is
> >        not getting control after that (program runs up to end)
>
> I found that the change that breaks FSDB is update from r1.12 to r1.14  
> for src/debug/common/dbgcom.c (r1.13 didn't compile) in July. So 
> unless there is some evident bug which can be easily fixed, maybe we 
> should revert this patch

Does the patch below fix the problem?

I don't think the changes in dbgcom.c are incorrect.  I think this is an 
old bug in FSDB (EDEBUG has similar problems) that was exposed by the 
change in dbgcom.c, which by itself was quite innocent.  The real 
problem is that FSDB used an old v1.x code which was setting the debug 
registers directly, whereas in v2.x this is handled by a DPMI function.  
The old code was adding the application base address (since the debug 
registers need a linear address), while in the v2.x version this is done 
in _set_break_DPMI.  This only worked because previously dbgcom.c failed
to initialize the edi.app_base member, so it stayed zero.  The change in 
dbgcom.c that triggered the bug was to initialize edi.app_base with the 
real base address.

I understand that it is not safe to manipulate the base address in the 
debugger's source because the base address can change (due to sbrk 
operation), which is why _set_break_DPMI gets the application's DS base 
address right before it uses it, each time it is called.  (In contrast, 
in v1.x the base address was a fixed value IIRC>)

Morten and DJ, do you agree that the addition of app_base should now be 
removed from the debuggers' source?

*** src/debug/fsdb/fullscr.c~0	Sun Jul 11 13:27:46 1999
--- src/debug/fsdb/fullscr.c	Tue Sep 21 21:46:02 1999
*************** activate_breakpoints (void)
*** 706,712 ****
  	bep->saved = 0;
  	edi.dr[7] |= ((bep->type + ((bep->length - 1) << 2)) << (16 + 4 * no)
  		      | (2 << (2 * no)));
! 	edi.dr[no] = bep->addr + edi.app_base;
  	no++;
        }
  
--- 706,712 ----
  	bep->saved = 0;
  	edi.dr[7] |= ((bep->type + ((bep->length - 1) << 2)) << (16 + 4 * no)
  		      | (2 << (2 * no)));
! 	edi.dr[no] = bep->addr;
  	no++;
        }
  
*************** activate_breakpoints (void)
*** 718,724 ****
  	{
  	  bep->saved = 0;
  	  edi.dr[7] |= ((BP_Code << (16 + 4 * no)) | (2 << (2 * no)));
! 	  edi.dr[no] = bep->addr + edi.app_base;
  	  no++;
  	  edi.dr[7] |= 0x00000300L;  /* For 386s we set GE & LE bits.  */
  	}
--- 718,724 ----
  	{
  	  bep->saved = 0;
  	  edi.dr[7] |= ((BP_Code << (16 + 4 * no)) | (2 << (2 * no)));
! 	  edi.dr[no] = bep->addr;
  	  no++;
  	  edi.dr[7] |= 0x00000300L;  /* For 386s we set GE & LE bits.  */
  	}
*************** step (KIND_TYPE kind)
*** 1136,1142 ****
  	  {
  	    no = get_breakpoint (((edi.dr[7] >> (16 + 4 * b)) & 3),
  				 ((edi.dr[7] >> (18 + 4 * b)) & 3) + 1,
! 				 edi.dr[b] - edi.app_base);
  	    break;
  	  }
        if (no == -1)
--- 1136,1142 ----
  	  {
  	    no = get_breakpoint (((edi.dr[7] >> (16 + 4 * b)) & 3),
  				 ((edi.dr[7] >> (18 + 4 * b)) & 3) + 1,
! 				 edi.dr[b]);
  	    break;
  	  }
        if (no == -1)