Mail Archives: djgpp/2015/05/24/04:17:40
On 05/21/2015 07:01 PM, Eli Zaretskii (eliz AT gnu DOT org) wrote:
>> 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?
Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
symptoms described earlier)
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf
Debugging DJGPP programs worked before this commit, but not after that. Used test executable for
testing whether GDB works OK was cc1.exe from my build of gcc-4.8.4 (HDDs are large now and I still
have build directory) in stage 3. Tested criteria: successful stepping into program, no error
messages, backtrace works reasonably well.
Andris
- Raw text -