Mail Archives: djgpp/2015/05/21/12:02:20
> 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
- Raw text -