X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <55618917.7080608@iki.fi> Date: Sun, 24 May 2015 11:17:27 +0300 From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: New GDB versions and DJGPP (Was: ANNOUNCE: DJGPP 2.05 beta 1) References: <201505042003 DOT t44K3odg011007 AT delorie DOT com> <55579278 DOT 8090301 AT iki DOT fi> <555829A6 DOT 8010502 AT iki DOT fi> <555870E8 DOT 7040302 AT iki DOT fi> <201505180114 DOT t4I1EiaX017288 AT envy DOT delorie DOT com> <201505181216 DOT t4ICGaKO014123 AT envy DOT delorie DOT com> <83zj52dkns DOT fsf AT gnu DOT org> <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> <83vbfl6hs9 DOT fsf AT gnu DOT org> In-Reply-To: <83vbfl6hs9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com 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)" >> >> 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