[Bug c++/45690] broken debuginfo with dwarf4?

[tromey at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

--- Comment #7 from Tom Tromey tromey at gcc dot gnu.org 2012-01-20 14:59:51 
UTC ---
gdb doesn't read .debug_pubtypes.
So the problem must be something else.

[Bug c++/45690] broken debuginfo with dwarf4?

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |tromey at gcc dot gnu.org

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-18 
11:36:19 UTC ---
Maybe Tom can have a look, see if something (still) makes sense here.

[Bug c++/45690] broken debuginfo with dwarf4?

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-18 
14:28:51 UTC ---
The problem is that the DWARF4 standard says that .debug_pubtypes resp.
.debug_pubnames refer to .debug_info section offsets and this hasn't been
updated for the (optional) .debug_types section addition.  If a type (resp.
name) DIE is instead in .debug_types section, it is unclear what should be
done.
Either such a type shouldn't be added into .debug_pubtypes at all, or we'd need
to refer to something.  I don't see anything to refer to in .debug_info section
though, usually it just contains DW_AT_type with DW_FORM_sig8 containing the
.debug_types hash with the type.  And it isn't possible to refer to
.debug_types section offsets, because the consumers would need a way to
differentiate between what is a .debug_info offset in the header (relative to
start of .debug_info) and what is a .debug_types offset (relative to start of
.debug_types).
I think currently what you see is gcc emitting offsets within containing
.debug_types section in .debug_pubtypes chunks corresponding to .debug_info.

[Bug c++/45690] broken debuginfo with dwarf4?

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

--- Comment #3 from Pawel Sikora pluto at agmk dot net 2010-10-14 11:13:10 
UTC ---
Created attachment 22036
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22036
my gcc build script.

[Bug c++/45690] broken debuginfo with dwarf4?

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

--- Comment #4 from Pawel Sikora pluto at agmk dot net 2010-10-14 11:17:55 
UTC ---
attached gcc build script builds libstdc++.a with dwarf3 debuginfo
which works with testcase compiled with dwarf3 or dwarf4.
if you change CUSTOM_FLAGS in build script to emit dwarf4 for libstdc++.a
then you'll get runtime error in python gdb printer.

[Bug c++/45690] broken debuginfo with dwarf4?

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2010-09-16 14:01 ---
Created an attachment (id=21811)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21811action=view)
source, makefile and precompiled binaries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690

[Bug c++/45690] broken debuginfo with dwarf4?

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2010-09-16 21:02 ---
ha, my gcc was built with: export CXXFLAGS=-O2; ./configure
--disable-shared...
and this CXXFLAGS afaics affects libstdc++.a debuginfo level.
with CXXFLAGS=-O2 -g2 the python pretty printer works fine.

testcase compiled with -gdwarf-4 -g2 and linked with stripped libstdc++.a
ends with undebugable std::string. of course with -gdwarf-3 everything
works fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690