Mail Archives: djgpp-workers/2012/12/12/19:15:53
Am 12.12.2012 17:22, schrieb Eli Zaretskii:
> > 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).
[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
- Raw text -