X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Date: Thu, 21 May 2015 19:01:58 +0300
From: "Eli Zaretskii (eliz AT gnu DOT org)" <djgpp AT delorie DOT com>
Subject: Re: ANNOUNCE: DJGPP 2.05 beta 1
In-reply-to: <555D5E30.7020107@iki.fi>
X-012-Sender: halo1 AT inter DOT net DOT il
To: djgpp AT delorie DOT com
Message-id: <83vbfl6hs9.fsf@gnu.org>
References: <201505042003 DOT t44K3odg011007 AT delorie DOT com> <55579278 DOT 8090301 AT iki DOT fi> <CAA2C=vBaQKzmch_buxFm20DJLcG+zv6d6803+qMEx=baA4Frog AT mail DOT gmail DOT com> <555829A6 DOT 8010502 AT iki DOT fi> <CAA2C=vA73qPvoDFytp3FeW6bCD1-XuGsFFoDinoKn2KYY1fkow AT mail DOT gmail DOT com> <555870E8 DOT 7040302 AT iki DOT fi> <CAA2C=vDhD6BJj89o1i0FRd2U0H4bTpGGN4zH6qs7FJKxzqhuQg AT mail DOT gmail DOT com> <201505180114 DOT t4I1EiaX017288 AT envy DOT delorie DOT com> <CAA2C=vCyrQ_+Yq6XsRD-UO4r=j9WoGGiXoqQFrkbiEQpzX+=MA AT mail DOT gmail DOT com> <201505181216 DOT t4ICGaKO014123 AT envy DOT delorie DOT com> <CAA2C=vCk5MY74z+HNVzzdLByg71Y_9ObK-1jPxJ_KF8eqRDZMQ AT mail DOT gmail DOT com> <83zj52dkns DOT fsf AT gnu DOT org> <CAA2C=vAPcN+MKC_2tcZqVmo9gvF2Cxdo+K+-qfKaNrQuCkMnEw AT mail DOT gmail DOT com> <555A0DD5 DOT 1010607 AT iki DOT fi> <83r3qdemuj DOT fsf AT gnu DOT org> <555AADE6 DOT 3030905 AT iki DOT f> <83lhgkehn4 DOT fsf AT gnu DOT org> <201505191714 DOT t4JHEr0B010992 AT envy DOT delorie DOT com> <83vbfo7a74 DOT fsf AT gnu DOT org> <201505191729 DOT t4JHTIRe011541 AT envy DOT delorie DOT com>
 <83sias77km DOT fsf AT gnu DOT org> <555CFF9C DOT 1050301 AT gmx DOT de> <555D5E30 DOT 7020107 AT iki DOT fi>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 21 May 2015 07:25:20 +0300
> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
> 
> This change is most likely only a result of other changes. So if we do not know these other changes
> it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is
> accidentally left out.

Juan quoted a discussion from a year ago, which ended with this
conclusion:

> >> (gdb) r
> >> Starting program: h:/l/bins/bin/a.exe
> >> Warning:
> >> Cannot insert breakpoint 1.
> >> Cannot access memory at address 0x1e04
> > This means inserting a breakpoint at 0x1e04 returned EIO.  I suggest
> > to take a good look at the code that's involved in this.  I see that
> > in GDB-7.7.1, we had these 2 lines in go32-nat.c:
> >
> >    go32_ops.to_insert_breakpoint = memory_insert_breakpoint;
> >    go32_ops.to_remove_breakpoint = memory_remove_breakpoint;
> >
> > but these lines are no longer there, and instead the go32 target
> > inherits from inf_child_target.  Perhaps that's the cause of the
> > problem.
> 
> Thank you for the pointer.  The change from the old way to handle the
> native support to the new way of initializing struct target_ops inf_child_ops
> by inf_child_target and go32_target seems to be the source of the difficulties.
> At least go32_ops.to_insert_breakpoint and go32_ops.to_remove_breakpoint are
> not set to the corresponding equivalent new variables for DJGPP.

Can we pick up where this was left off?

FWIW, I don't understand what Juan wrote back then: go32_ops no longer
exists in the current sources.  Instead, the initialization calls
go32_target, which does this:

  static struct target_ops *
  go32_target (void)
  {
    struct target_ops *t = inf_child_target ();

In inf_child_target, I see that to_insert_breakpoint and
to_remove_breakpoint are correctly assigned:

  struct target_ops *
  inf_child_target (void)
  {
    struct target_ops *t = XCNEW (struct target_ops);

  [...]
    t->to_insert_breakpoint = memory_insert_breakpoint;
    t->to_remove_breakpoint = memory_remove_breakpoint;

Back in the go32-nat initialization function, we have this call, after
all the members of target_ops were initialized:

  add_target (t);

where before GDB 7.8 it did this instead:

  add_target (&go32_ops);

This all looks OK to me, and I just stepped through the corresponding
code for the MinGW native target and saw that it does the same (and
certainly works, as I use it every day).

So what and how goes wrong in the DJGPP build of GDB?  Can someone
with enough free time step through the go32 initialization, and see
what's wrong there?

TIA