X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com X-Authenticated: #27081556 X-Provags-ID: V01U2FsdGVkX19hwYkY3JZhsdQ9eL5+Nw/9W7TOKbsR03vs6o5RzB uzHxJPqatqg+fY Message-ID: <50C91E2A.2050809@gmx.de> Date: Thu, 13 Dec 2012 01:15:38 +0100 From: Juan Manuel Guerrero User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: RFC: remove deprecated_sym_private References: <87sj7c9u95 DOT fsf AT fleche DOT redhat DOT com> <83r4mw7x68 DOT fsf AT gnu DOT org> <50C87C50 DOT 3050704 AT gmx DOT de> <83fw3b8cl8 DOT fsf AT gnu DOT org> In-Reply-To: <83fw3b8cl8.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Reply-To: djgpp-workers AT delorie DOT com Am 12.12.2012 17:22, schrieb Eli Zaretskii: > > 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). [snip] > > > > 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. Yes. The bottom line is if the things are broken, then they are broken since a couple of years and these patches will not make things worse than they already are. On the other hand if things still work these patches will not break anything. [snip] > > 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. I tested this too but I have forgot to mention it. It is possible to step through the temacs binary using the patched GDB. Of course, it is also possible to step inside temecs functions and to set new break- point during the debug session. AFAIK it is possible to run a normal debug session with the patched GDB with the emacs sources. This may not be true for other sources compiled with -gcoff option. > 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?) I have incremented the a.exe stack to 2MB and to 10MB. It still does not work. I also reduced emacs.exe stack to 512KB and I was still able to successfully step through the code. > Also, does objdump succeed to show line number info in a.exe? No. objdump is not able to read neither line numbers nor inserted source code lines. All objdump before bnu219b are able to read line numbers und inserted code lines but starting with bnu219 this is no longer possible. This applies only if compiled with -gcoff option. BTW it make no difference if I use tools from /current or /beta diretory but this should be clear. Regards, Juan M. Guerrero