Mail Archives: djgpp/2015/05/20/16:53:45
Am 19.05.2015 20:20, schrieb Eli Zaretskii (eliz AT gnu DOT org):
>> Date: Tue, 19 May 2015 13:29:18 -0400
>> From: DJ Delorie<dj AT delorie DOT com>
>>
>>> Yes, I agree. So if we no longer have a reason to include GCC's
>>> headers while building the library, we should remove that inclusion
>>> from makefile.inc, I think.
>>
>> Exception: if the "reason" is "the headers are broken", then we should
>> instead fix the headers. Otherwise, users will not get the same
>> headers as libc, and will/may still see the broken behavior.
>
> Right.
>
>> What's wrong with the debug info?
>
> I don't really know, I never upgraded beyond GCC 3.4 and GDB 6.8,
> because these two can still be used to debug executables with COFF
> debug info. (I need COFF for Emacs.)
>
> Juan probably knows much more, as he built every version of GDB until
> now, and it's from him that I know that COFF debugging is unusable
> with latest versions of GCC and GDB.
Today I have ported and compiled gdb-7.9.1.tar.gz. The COFF/dwarf support is
as broken as with gdb-7.8. and later versions. The last gdb version with working
djgpp support is gdb-7.7.1.tar.gz. I do not think that they have intentionally
removed or brocken djgpp support. But an inspection of the changelog file shows
that they have modified go32-nat.c but not only this one. This change seems to be
part of a major modification or rewrite of that particular code segments.
From Changelog-2014:
2014-03-07 Pedro Alves <palves AT redhat DOT com>
* go32-nat.c: Include inf-child.h.
(go32_ops): Delete global.
(go32_close, go32_detach, go32_prepare_to_store, go32_can_run):
Delete methods.
(go32_create_inferior): Push the passed in target pointer instead
of referencing go32_ops.
(init_go32_ops): Delete function. Moved parts to _initialize_go32_nat.
(go32_target): New function, based on init_go32_ops, but inherit
inf_child_target.
(_initialize_go32_nat): Use go32_target. Move parts of
init_go32_ops here.
I have inspected those changes and they seem to have been well done. So it is
not clear what has been brocken.
Unfortunately I have absolute no knowledge about DWARF and especially I do not
understand how the djgpp support of gdb works. So I cannot debug nor figure out
this issue.
Unfortunately I have no other COFF/dwarf2 system to check if it is brocken too.
Of course I exclude PE-COFF. If this target would have been brocken then
a lot of complains would have been sended to the gdb mailing list. And of course
PE-COFF is not really the same than COFF.
I have compiled this gdb port using djdev204, gcc492 and bnu224br2. I have
intentionally used djdev204 to avoid the inference of any bugs that may be
present in djdev205 and bnu225b (because compiled with djdev205). The pain
is not worth to try to compile this gdb port using djdev203. It would also
not work as the port of gdb 7.8 has already not worked.
I have compiled a simple hello-world program using the same configuration than
the one used to compile the gdb port. It fails the same way it used to fail
with gdb 7.8. Nothing changed compared against that version.
Please note that the same program can be flawlessly debugged using the gdb 7.7.1
port! So this is certainly something brocken or in gdb or in bfd but not in our
libraries and ports.
For more information pleace read the thread:
<http://www.delorie.com/archives/browse.cgi?p=djgpp/2014/08/08/14:46:57>
Regards,
Juan M. Guerrero
C:\tmp\5>a
qwertz
C:\tmp\5>gdb a.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...done.
(gdb) b main
Breakpoint 1 at 0x1ed8: file a.c, line 4.
(gdb) r
Starting program: c:/tmp/5/a.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8
(gdb) s
Single stepping until exit from function start,
which has no line number information.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8
Cannot insert breakpoint -2.
Cannot access memory at address 0x57b0
(gdb)
- Raw text -