Mail Archives: djgpp-workers/2012/12/12/11:23:14
> Date: Wed, 12 Dec 2012 13:45:04 +0100
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> CC: djgpp-workers AT delorie DOT com
>
> After some tinkering I managed to apply both patches to
> gdb-7.5.50.20121212.tar.bz2 (current) and gdb-7.5.1.20121212.tar.bz2(branch).
> I compiled using g[cc|pp]472b, bnu2231b and a snapshot of today's CVS repository.
> The result is very strange. I do not understand what is going wrong here.
> All test programs to check for working -gcoff support have been compiled using
> gcc344b, bnu2231b and a snapshot of today's CVS repository. If I compile a
> simple "hello world" program using the compiler options "-gcoff -O0" I get
> a working binary that cannot be debuged because GDB is not able to find the
> program lines in the binary. GDB gives the following output:
>
> G:\srcs\bins2\bin>gdb a.exe
> GNU gdb (GDB) 7.5.50.20121212
> Copyright (C) 2012 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 g:/srcs/bins2/bin/a.exe...done.
> (gdb) b main
> Breakpoint 1 at 0x1723
> (gdb) r
> Starting program: g:/srcs/bins2/bin/a.exe
>
> Breakpoint 1, 0x00001723 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> hello world
> [Inferior 1 (process 42) exited normally]
> (gdb)
>
>
> The only debuggers that are able to identify coff debug line numbers in this
> test program are: gdb53b, gdb64b and gdb72b. Starting with gdb73b no GDB is
> able to identify the line numbers.
So these patches do not make things worse.
> As a second test I compiled emacs 23.0.3 (em2303b) under the same conditions
> as before. The really surprising fact is that now all tested GDBs are able
> to step through emacs.exe. emacs has been compiled with -gcoff -O0. Again
> I am able to single step trough emacs code using gdb 7.5.50.20121212 after
> having applied both patches.
So again, nothing seems to be wrong after applying the patches that
wasn't wrong before that.
> Although I have inspected the makefile from emacs I was not able to figure out
> what is special or different in the emacs compilation compared with the compilation
> of the "hello world" program.
There's nothing special, Emacs just uses -gcoff. The only possible
difference is that Emacs then dumps itself, which involves rewriting
the debug info. But that isn't supposed to change the debug info in
any way. Just in case, try running temacs.exe under GDB, and see if
that works.
Hmm... just had an idea: maybe the problem is the stack size. Emacs
is stubedit'ed to 2MB stack. So maybe try doing the same with your
hello world program, and see if that helps. (Not that I think we use
the stub-recorded info when we debug programs, but who knows?)
Also, does objdump succeed to show line number info in a.exe?
> Until this has not been resolved I think it makes no much sense to
> CC messages to gdb-patches AT sourceware DOT org.
Agreed.
Thanks for testing this.
- Raw text -