X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Date: Wed, 12 Dec 2012 18:22:27 +0200 From: Eli Zaretskii Subject: Re: RFC: remove deprecated_sym_private In-reply-to: <50C87C50.3050704@gmx.de> X-012-Sender: halo1 AT inter DOT net DOT il To: Juan Manuel Guerrero Cc: djgpp-workers AT delorie DOT com Message-id: <83fw3b8cl8.fsf@gnu.org> References: <87sj7c9u95 DOT fsf AT fleche DOT redhat DOT com> <83r4mw7x68 DOT fsf AT gnu DOT org> <50C87C50 DOT 3050704 AT gmx DOT de> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Wed, 12 Dec 2012 13:45:04 +0100 > From: Juan Manuel Guerrero > 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 > 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: > ... > 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.