Mail Archives: djgpp/2016/04/29/04:34:02
> Date: Fri, 29 Apr 2016 00:34:20 +0200
> From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
>
> There is absolute nothing broken with binutils 2.26. The only thing broken
> is gdb's capability of supporting coff debug information. I have compiled the
> sample program I have attached in the previous mail using djdev205, gcc346 und
> bnu226br3 using -gcoff -O0 flags.
It turns out I had bnu226b installed, not bnu226br3. Installing the
latter does indeed allow me to debug your test program and also debug
Emacs, thanks. (Is there really such a big difference between bnu226b
and bnu226br3?)
> The __only__ DJGPP ports of gdb that are capable to step through the
> code are gdb53b and gdb64b and no other ones.
I have a build of a (pretest of) GDB 6.9, and it does work with COFF
debug info. I have been using that build for many years when I needed
to debug DJGPP Emacs. It is an old v2.03 build, so I hope I won't run
into issues with low-level incompatibilities wrt v2.05 compiled
binaries.
I see no binary packages for GDB 5.3 or 6.4 on DJGPP FTP sites,
certainly not in the 'current' tree. The 'current.old' tree has GDB
5.3 and 6.1.1 (or is it 6.11?), but not 6.4.
> I do not know who has claimed something different, but it is certainly not true.
Andris said back in June 7.7 was okay. Admittedly, he only tested
that on a very small program.
> The port gdb72b is still capable to step into main function but has lost its
> capability to step into functions. This means that you can only step through
> the code of the main function and nothing else. _All_ other DJGPP ports of gdb
> starting with gdb73b are completely broken concerning coff debug support and
> cannot be used at all. Starting with gdb73, you will get the well known error
> message:
> H:\_TEST_PR>gdb main.exe
> GNU gdb (GDB) 7.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> 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".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from h:/_test_programme_/main.exe...done.
> (gdb) b main
> Breakpoint 1 at 0x160d
> (gdb) r
> Starting program: h:/_test_programme_/main.exe
>
> Breakpoint 1, 0x0000160d in main ()
> (gdb) s
> Single stepping until exit from function main,
> which has no line number information.
> string(12) = foobarqwertz
> 0x00003c2c in __crt1_startup ()
> (gdb)
>
>
> I have repeated this experiment three more times, first using bnu214 and then
> bnu219 instead of bnu226br3. The results are absolute the same!!! The last
> debugger that supports coff debug info is gdb64 and no one else. I have
> repeated the experiment a third with a freshly compiled version bnu219. For
> this purpose djdev205, gcc346 and bnu219 have been used to compile the new as
> and ld. It was clear that this would be a complete waist of time because it
> was clear that the used library would have no impact on the broken coff debug
> support either in gcc or gdb or as or ld. The outcome was the same again:
> gdb53b and gdb64b are OK but any other version of gdb is absolutely useless.
> The bottom line is, it does not matter what binutils are used; you must use
> the right gdb version.
OK, thanks for this information. I can only add that 6.9 seems to be
OK as well -- as long as Binutils 2.26r3 are used. Perhaps we could
have v2.05 compiled GDB 6.9 on DJGPP sites?
> If gdb64 is not good enough to debug emacs issues, then we have reach the end
> of the road of the DJGPP port of emacs. I have neither the skills nor the time
> to fix broken coff debug support neither in binutils nor in gdb.
I will address this important issue in a separate message.
Thanks.
- Raw text -