Mail Archives: djgpp-workers/2012/12/12/07:45:18
Am 12.12.2012 04:43, schrieb Eli Zaretskii:
> Could some of you please test this patch with DJGPP GDB and see if the
> ability to debug binaries produced with -gcoff is harmed in any way?
>
> Please report the results directly to gdb-patches AT sourceware DOT org.
>
>Thanks in advance.
[snip]
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. Of course, it is always possible to step
through the assembler code of the program. But that is not really useful in
this case.
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.
Only for the record: the hello world program is like this:
------------------ start ----------------------
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
------------------ end ----------------------
compiled with:
gcc -Wall -gcoff -O0 1.c
All used tools are from the /beta directory. All programs to test -gcoff support
have been compiled using gcc344b, bnu2231b and a freshly compiled djdev204 from
today's repository sources. All GDBs have been compiled using g[cc|pp]472b,
bnu2231b and the same freshly compiled djdev204 from today's repository sources.
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. Until this has not been resolved I think it makes no
much sense to CC messages to gdb-patches AT sourceware DOT org.
If more information is needed, please contact me.
Regards,
Juan M. Guerrero
- Raw text -