X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <555CFF9C.1050301@gmx.de> Date: Wed, 20 May 2015 23:41:48 +0200 From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de)" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7 MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: 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> In-Reply-To: <83sias77km.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DHyKAjttH11vFDM3so2YZDCNbCS8I6/VaEgHC/bjxNTPqRJTnzW f2OrxaJb0Joll1pgxI1YLoJe9gJsJRAzsYMIce4CKqEtDBjyvcnQbcfWBLopUjx/vbdgBSS 8xh4qllIV5LbsFulConLKQNf9VR5pb83Wvtfp/BvicsH7+AUVT77FeCF4e95GH/qBVaiKbx h5A+mib4wTqso6KWYr8Eg== X-UI-Out-Filterresults: notjunk:1; Reply-To: djgpp AT delorie DOT com Am 19.05.2015 20:20, schrieb Eli Zaretskii (eliz AT gnu DOT org): >> Date: Tue, 19 May 2015 13:29:18 -0400 >> From: DJ Delorie >> >>> Yes, I agree. So if we no longer have a reason to include GCC's >>> headers while building the library, we should remove that inclusion >>> from makefile.inc, I think. >> >> Exception: if the "reason" is "the headers are broken", then we should >> instead fix the headers. Otherwise, users will not get the same >> headers as libc, and will/may still see the broken behavior. > > Right. > >> What's wrong with the debug info? > > I don't really know, I never upgraded beyond GCC 3.4 and GDB 6.8, > because these two can still be used to debug executables with COFF > debug info. (I need COFF for Emacs.) > > Juan probably knows much more, as he built every version of GDB until > now, and it's from him that I know that COFF debugging is unusable > with latest versions of GCC and GDB. Today I have ported and compiled gdb-7.9.1.tar.gz. The COFF/dwarf support is as broken as with gdb-7.8. and later versions. The last gdb version with working djgpp support is gdb-7.7.1.tar.gz. I do not think that they have intentionally removed or brocken djgpp support. But an inspection of the changelog file shows that they have modified go32-nat.c but not only this one. This change seems to be part of a major modification or rewrite of that particular code segments. From Changelog-2014: 2014-03-07 Pedro Alves * go32-nat.c: Include inf-child.h. (go32_ops): Delete global. (go32_close, go32_detach, go32_prepare_to_store, go32_can_run): Delete methods. (go32_create_inferior): Push the passed in target pointer instead of referencing go32_ops. (init_go32_ops): Delete function. Moved parts to _initialize_go32_nat. (go32_target): New function, based on init_go32_ops, but inherit inf_child_target. (_initialize_go32_nat): Use go32_target. Move parts of init_go32_ops here. I have inspected those changes and they seem to have been well done. So it is not clear what has been brocken. Unfortunately I have absolute no knowledge about DWARF and especially I do not understand how the djgpp support of gdb works. So I cannot debug nor figure out this issue. Unfortunately I have no other COFF/dwarf2 system to check if it is brocken too. Of course I exclude PE-COFF. If this target would have been brocken then a lot of complains would have been sended to the gdb mailing list. And of course PE-COFF is not really the same than COFF. I have compiled this gdb port using djdev204, gcc492 and bnu224br2. I have intentionally used djdev204 to avoid the inference of any bugs that may be present in djdev205 and bnu225b (because compiled with djdev205). The pain is not worth to try to compile this gdb port using djdev203. It would also not work as the port of gdb 7.8 has already not worked. I have compiled a simple hello-world program using the same configuration than the one used to compile the gdb port. It fails the same way it used to fail with gdb 7.8. Nothing changed compared against that version. Please note that the same program can be flawlessly debugged using the gdb 7.7.1 port! So this is certainly something brocken or in gdb or in bfd but not in our libraries and ports. For more information pleace read the thread: Regards, Juan M. Guerrero C:\tmp\5>a qwertz C:\tmp\5>gdb a.exe GNU gdb (GDB) 7.9.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from a.exe...done. (gdb) b main Breakpoint 1 at 0x1ed8: file a.c, line 4. (gdb) r Starting program: c:/tmp/5/a.exe Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x1ed8 (gdb) s Single stepping until exit from function start, which has no line number information. Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x1ed8 Cannot insert breakpoint -2. Cannot access memory at address 0x57b0 (gdb)