[Bug default/20369] New: Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[Bug default/20369] New: Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

            Bug ID: 20369
           Summary: Assertion `m' failed in abidw:
                    abg-dwarf-reader.cc:7472
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: andrew.c.morrow at gmail dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 9389
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9389&action=edit
reproducing library

At libabigail commit 5b9ef4d091961d87663492cb742625c7edee796d, I'm getting the
following assertion with the attached library:

abidw: abg-dwarf-reader.cc:7472: void
abigail::dwarf_reader::finish_member_function_reading(Dwarf_Die*,
abigail::ir::function_decl_sptr, abigail::ir::class_decl_sptr,
abigail::dwarf_reader::read_context&): Assertion `m' failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #7 from andrew.c.morrow at gmail dot com ---
I did some further building, and it appears that all of the assertion failures
reported earlier do not reproduce if -fdebug-types-section is not used.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #3 from andrew.c.morrow at gmail dot com ---
I just downloaded the file that I uploaded, and it doesn't look stripped to me:

$ file reproducer.so
reproducer.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, BuildID[sha1]=0cb163f188a21efab9e10240a63050f6a012deb0, not
stripped

$ cksum reproducer.so
2550113353 4286489 reproducer.so

$ readelf -a reproducer.so  | grep '\.debug'
  [31] .debug_types      PROGBITS         0000000000000000  000d0de8
  [32] .debug_info       PROGBITS         0000000000000000  001706a5
  [33] .debug_abbrev     PROGBITS         0000000000000000  00332682
  [34] .debug_loc        PROGBITS         0000000000000000  0034a962
  [35] .debug_aranges    PROGBITS         0000000000000000  003aab4b
  [36] .debug_ranges     PROGBITS         0000000000000000  003ab803
  [37] .debug_line       PROGBITS         0000000000000000  003bf0dc
  [38] .debug_str        PROGBITS         0000000000000000  003e0cff

$ ~/opt/bin/abidw reproducer.so
abidw: abg-dwarf-reader.cc:7472: void
abigail::dwarf_reader::finish_member_function_reading(Dwarf_Die*,
abigail::ir::function_decl_sptr, abigail::ir::class_decl_sptr,
abigail::dwarf_reader::read_context&): Assertion `m' failed.
Aborted (core dumped)

$ ~/opt/bin/abidw --version
1.0.rc6

I built that version of abidw from e88892c0b1f49c0d9ca64617b1c3423979b51053 as
follows:

$ autoreconf -fiv && ./configure --enable-cxx11 --enable-shared
--disable-static --with-gnu-ld --prefix=$HOME/opt && make -j18 all && make
intall

The library was though linked with -Wl,--compress-debug-sections=zlib-gabi. I
wonder if that has something to do with it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #20 from andrew.c.morrow at gmail dot com ---
(In reply to dodji from comment #19)
> This issue should now be resolved by commit
> https://sourceware.org/git/?p=libabigail.git;a=commit;
> h=8b2f4ac43f1d3361eb1069b43f39385fc5bf5611 from the master branch of the git
> repository.
> 
> The fix should thus be available in the next 1.0.rc6 release of the
> libabigail package.
> 
> Thank you for taking the time to report this problem!

Just pulled the latest and I can confirm that this issue no longer occurs. All
shared libraries in the mongodb build again run without error under abidw.
Thanks for the quick fix!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #9 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to dodji from comment #8)
> The reason why I thought the binary was stripped is that my version of
> elfutils couldn't read the debug info from that binary:
> [...]
> dodji@adjoa:PR20369$ rpm -q elfutils
> elfutils-0.163-3.el7.x86_64
> dodji@adjoa:PR20369$

Compressed ELF section support was added to elfutils 0.165.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[Dodji Seketeli]

"mjw at redhat dot com" <sourceware-bugzilla@sourceware.org> a écrit:

> Compressed ELF section support was added to elfutils 0.165.

Right.  So I am assuming that Andrew is using an elfutils which version
is >= 0.165.

"andrew.c.morrow at gmail dot com"
<sourceware-bugzilla@sourceware.org> a écrit:

> --- Comment #7 from andrew.c.morrow at gmail dot com ---
> I did some further building, and it appears that all of the assertion failures
> reported earlier do not reproduce if -fdebug-types-section is not
> used.

Thanks for the insight, Andrew.  I could reproduce the issue now with
elfutils compiled from the master branch of its Git repository.

I need to look at this more closely, but I am guessing that libabigail's
DWARF reader now needs to support the debug informatin entries of tag
DW_TAG_type_unit (that are emitted when the compiler flag
-fdebug-types-section is emitted) which it doesn't support yet.

-- 
		Dodji

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

andrew.c.morrow at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9396|libbase.so.bood             |libbase.so.good
        description|                            |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #19 from dodji at redhat dot com ---
This issue should now be resolved by commit
https://sourceware.org/git/?p=libabigail.git;a=commit;h=8b2f4ac43f1d3361eb1069b43f39385fc5bf5611
from the master branch of the git repository.

The fix should thus be available in the next 1.0.rc6 release of the libabigail
package.

Thank you for taking the time to report this problem!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #1 from andrew.c.morrow at gmail dot com ---
I have about five more assertion failures at that commit. Each one reproduces
in a different library, which I can upload if needed, but in case they share a
similar root cause, here are the other assertions I'm seeing:

abidw: abg-dwarf-reader.cc:7909: abigail::ir::qualified_type_def_sptr
abigail::dwarf_reader::build_qualified_type(abigail::dwarf_reader::read_context&,
Dwarf_Die*, bool, bool, size_t): Assertion `utype' failed.

abidw: abg-dwarf-reader.cc:6904: abigail::ir::scope_decl_sptr
abigail::dwarf_reader::get_scope_for_die(abigail::dwarf_reader::read_context&,
Dwarf_Die*, bool, bool, size_t): Assertion `i != ctxt.die_tu_map().end()'
failed.

abidw: abg-dwarf-reader.cc:8500: abigail::ir::typedef_decl_sptr
abigail::dwarf_reader::build_typedef_type(abigail::dwarf_reader::read_context&,
Dwarf_Die*, bool, bool, size_t): Assertion `utype' failed.

abidw: abg-dwarf-reader.cc:9111: abigail::ir::type_or_decl_base_sptr
abigail::dwarf_reader::build_ir_node_from_die(abigail::dwarf_reader::read_context&,
Dwarf_Die*, bool, abigail::ir::scope_decl*, bool, size_t): Assertion `klass'
failed.

abidw: abg-dwarf-reader.cc:8039: abigail::ir::pointer_type_def_sptr
abigail::dwarf_reader::build_pointer_type_def(abigail::dwarf_reader::read_context&,
Dwarf_Die*, bool, bool, size_t): Assertion `utype' failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #11 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to dodji from comment #10)
> I need to look at this more closely, but I am guessing that libabigail's
> DWARF reader now needs to support the debug informatin entries of tag
> DW_TAG_type_unit (that are emitted when the compiler flag
> -fdebug-types-section is emitted) which it doesn't support yet.

In theory you shouldn't need to. Types moved into a type_unit are referenced by
DW_AT_type in the main types/DIEs in the CUs through a special kind of form
(DW_FORM_ref_sig8) which libdw dwarf_formref_die will resolve as any other
reference form. This is kind of like DW_FORM_GNU_ref_alt. Any type referenced
through that form will be resolved by dwarf_formref_die even though the DIE is
in a separate file. Normally when using libdw you shouldn't have to care
whether any DIE resolved comes from the same CU, and different CU, a separate
TU section or even an alternative debuginfo file.

Note that if you actually do want to also walk the raw type units you should
use dwarf_next_unit instead of dwarf_nextcu, providing a non-null
type_signaturep to store the signature of the type unit. See the documentation
in libdw.h for details.

But if you really care about the reference form or actualy type signature to
refer to a specific type DIE then I think we should improve the abstraction of
libdw so you don't have to care.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #15 from dodji at redhat dot com ---
"andrew.c.morrow at gmail dot com" <sourceware-bugzilla@sourceware.org>
writes:

Thank you for the information, Andrew.

[...]

> In any event, -fdebug-types-sections is a documented GCC option that
> certainly looks like a good thing to use, so I'd expect at least some
> projects to use it in the wild, in which case I think libabigail
> should be able to tolerate it.

Right, I am currently working on adding support for it.  I was just
curious about your feedback on the use of this option, as I haven't had
the chance to talk to anyone using it before.  It's nice to see that it
actually does reduce debuginfo size in practice.

Also, the fact that you are using ld.gold is an interesting data point.

Thanks again.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

andrew.c.morrow at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9389|0                           |1
        is obsolete|                            |

--- Comment #5 from andrew.c.morrow at gmail dot com ---
Created attachment 9395
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9395&action=edit
libbase.so.bad

This library, built with -fdebug-types-section crashes abidw.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |woodard at redhat dot com

--- Comment #16 from Ben Woodard <woodard at redhat dot com> ---
I just wanted to add a comment that --compress-debug-sections and DWZ are quite
different in their approaches. --compress-debug-sections simply uses zlib to
compress the DWARF while dwz actually replaces duplicated DWARF information
coming from different compilation units with references to each other. This is
particularly effective when applied to templated C++ code.

In theory once dwz has been applied the DWARF could even be compressed further
with zlib but I've never heard of anyone attempting this and I would be
surprised if it worked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #12 from dodji at redhat dot com ---
The main reason why I need to support the DW_TAG_type_unit specifically is that
elfutils doesn't provide a way to get the parent node of a given DIE.

So libabigail builds that relationship itself, where each DIE is identified by
its DIE offset. Because a DIE A coming from the .debug_info section, a DIE B
coming from the alternate debug insection and DIE C coming from the .type_units
section can all have the same offset even though they are different DIEs,
libabigail maintains three different "DIE -> parent DIE" hash tables; one for
.debug_info DIEs, one for alternate debug info DIE and one for the .type_units
DIEs.  Well, until now, we only had two, but now it's going to have three.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #22 from andrew.c.morrow at gmail dot com ---
FYI I've reported the above issue with dwz here:
https://bugzilla.redhat.com/show_bug.cgi?id=1399866

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2016-07-16
     Ever confirmed|0                           |1

--- Comment #2 from dodji at redhat dot com ---
I cannot reproduce the issue with the libbase.so binary that is attached. 
Furthermore, debug info for that binary seems to be stripped out.

Is it possible that the attached library is not the one you wanted to attach? 
If so, I'd need the correct library with its debug info.

Thanks, and sorry for the inconvenience.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #18 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to dodji from comment #12)
> The main reason why I need to support the DW_TAG_type_unit specifically is
> that elfutils doesn't provide a way to get the parent node of a given DIE.
> 
> So libabigail builds that relationship itself, where each DIE is identified
> by its DIE offset. Because a DIE A coming from the .debug_info section, a
> DIE B coming from the alternate debug insection and DIE C coming from the
> .type_units section can all have the same offset even though they are
> different DIEs, libabigail maintains three different "DIE -> parent DIE"
> hash tables; one for .debug_info DIEs, one for alternate debug info DIE and
> one for the .type_units DIEs.  Well, until now, we only had two, but now
> it's going to have three.

We discussed this on IRC already a little. But for the record if you want to
build a relationship yourself then identifying a DIE with just the offset isn't
enough. You can either use the Dwarf_Die addr field as unique identifier for a
DIE (you'll need to keep a copy of the Dwarf_Die then if you want to
reconstruct it). Or you can keep a pair of Dwarf_CU* and offsets to identify a
DIE. In the last case you can use the Dwarf_CU to extract the information from
which Dwarf/file and which section info/type the Dwarf_Die came and reconstruct
it with dwarf_offdie or dwarf_offdie_types as appropriate.

I saw the current code tries to second guess where libdw got a Dwarf_Die from
by inspecting the reference form of the referring Dwarf_Die. I believe that is
the wrong way to do this. Each Dwarf_Die has a cu field that provides the
information you need without having to do any low-level DWARF form parsing
yourself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #4 from andrew.c.morrow at gmail dot com ---
I think I've found the culprit. If the library is built with
-fdebug-types-section, then it crashes abidw for me, otherwise, abidw works.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #17 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to andrew.c.morrow from comment #14)
> I'd not heard that -fdebug-types-sections was disfavored

It is disabled by default since it splits the DIE tree into separate data
sections (.debug_info vs .debug_types) which confuses some tools and because
dwz compression gives bigger savings.

> As I mentioned elsewhere, I am also experimenting with
> -Wl,--compress-debug-sections=zlib-gabi, which I think is more or less the
> same thing as using 'dwz'. The improvements there are quite nice.

As Ben mentioned ELF zlib section compression is completely independent from
using debug_types or dwz. It is traditional lossless data compression that
doesn't know anything about the underlying DWARF data. dwz also works on
multiple DWARF files, making it possible to extract all common DWARF data into
a separate shared file. That makes it particular effective when a
program/package contains multiple shared libraries that share common data
structures.

In general I would recommend against using ELF section compression. Again some
tools don't know how to handle such compressed ELF sections and it trades disk
space for memory space and time. Which might not matter much for libabigail
which uses elfutils libdw and the newest versions should make the section
compression transparent. But for tools that only need small parts of the DWARF
data and that require fast startup for like profiling, tracing or interactive
debugging sessions it slows down startup and blows up memory (they can no
longer simply map the ELF files into memory and only access those parts they
need, but need to copy and decompress all data at startup).

A better alternative is what most distros do compressing the whole package for
transport, but make sure the full files are installed. Using file/package level
compression on separate debuginfo files also allows more effective compression
algorithms like lzma which compress much better than zlib.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
            Summary|Assertion `m' failed in     |Support DW_TAG_type_unit
                   |abidw:                      |
                   |abg-dwarf-reader.cc:7472    |
           Severity|critical                    |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #6 from andrew.c.morrow at gmail dot com ---
Created attachment 9396
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9396&action=edit
libbase.so.bood

This library, built without -fdebug-types-section, works fine with abidw.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #8 from dodji at redhat dot com ---
The reason why I thought the binary was stripped is that my version of elfutils
couldn't read the debug info from that binary:

dodji@adjoa:PR20369$ eu-readelf --debug-dump=info libbase.so

DWARF section [31] '.debug_types' at offset 0xd0de8:
 [Offset]

DWARF section [32] '.debug_info' at offset 0x1706a5:
 [Offset]
dodji@adjoa:PR20369$


dodji@adjoa:PR20369$ rpm -q elfutils
elfutils-0.163-3.el7.x86_64
dodji@adjoa:PR20369$

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #21 from andrew.c.morrow at gmail dot com ---
(In reply to Mark Wielaard from comment #17)
> (In reply to andrew.c.morrow from comment #14)
> > I'd not heard that -fdebug-types-sections was disfavored
> 
> It is disabled by default since it splits the DIE tree into separate data
> sections (.debug_info vs .debug_types) which confuses some tools and because
> dwz compression gives bigger savings.
> 
> > As I mentioned elsewhere, I am also experimenting with
> > -Wl,--compress-debug-sections=zlib-gabi, which I think is more or less the
> > same thing as using 'dwz'. The improvements there are quite nice.
> 
> As Ben mentioned ELF zlib section compression is completely independent from
> using debug_types or dwz. It is traditional lossless data compression that
> doesn't know anything about the underlying DWARF data. dwz also works on
> multiple DWARF files, making it possible to extract all common DWARF data
> into a separate shared file. That makes it particular effective when a
> program/package contains multiple shared libraries that share common data
> structures.
> 
> In general I would recommend against using ELF section compression. Again
> some tools don't know how to handle such compressed ELF sections and it
> trades disk space for memory space and time. Which might not matter much for
> libabigail which uses elfutils libdw and the newest versions should make the
> section compression transparent. But for tools that only need small parts of
> the DWARF data and that require fast startup for like profiling, tracing or
> interactive debugging sessions it slows down startup and blows up memory
> (they can no longer simply map the ELF files into memory and only access
> those parts they need, but need to copy and decompress all data at startup).
> 
> A better alternative is what most distros do compressing the whole package
> for transport, but make sure the full files are installed. Using
> file/package level compression on separate debuginfo files also allows more
> effective compression algorithms like lzma which compress much better than
> zlib.

Thank you for the information on dwz. I actually just tried it out, but it
doesn't seem to work for me:

$ dwz -m common.debug ./mongo.debug ./mongod.debug ./mongos.debug
dwz: Allocatable section in ./mongo.debug after non-allocatable ones
dwz: Allocatable section in ./mongod.debug after non-allocatable ones
dwz: Allocatable section in ./mongos.debug after non-allocatable ones
dwz: Too few files for multifile optimization

I think what is happening here is it has bailed out on each of the three files,
and then sort of reasonably concludes that the remaining files, of which there
are none, are not enough to work with.

A quick google around for the 'dwz: Allocator section..' message did not lead
to anything very promising.

Any suggestions on how to debug this, or for where to raise this question?

I'm also a little curious about the relationship between dwz and the whole
'debug fission' project and its tool dwp. Is -gsplit-dwarf still a think of
interest?

There seems to be a lot of great work out there about minimizing debug info,
but not a lot of guidance on which techniques are the right ones to use, and
which have become obsolete.

Anyway, here is the info on the version of dwz I have. The local system is
Ubuntu 16.04:

$ dwz --version
dwz version 0.12
Copyright (C) 2001-2012 Red Hat, Inc.
Copyright (C) 2003 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

What is the appropriate forum/project for working through issues with dwz? It
doesn't seem to be part of binutils.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #13 from dodji at redhat dot com ---
Andrew,

Just out of curiosity, are you seeing any gain from using
-fdebug-types-section?

Do you gain significant amount of memory after your linker (which linker is
it?) merged the types from the type sections emitted for the different
translation unit?

How does that compare to using the "dwz" compression tool?

I am asking because I had the impression that type sections were not really
used, since their seems to be a number of tools that still don't support them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Support DW_TAG_type_unit

[andrew.c.morrow at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #14 from andrew.c.morrow at gmail dot com ---
Well, based on libbase.so.bad (built with -fdebug-types-sections) and
libbase.so.good (built without) attached in this bug, it looks like using
-fdebug-types-sections shaved off about .4MB from the total file, so about a
10% reduction, which isn't nothing.

I'd not heard that -fdebug-types-sections was disfavored, nor have I done a
careful investigation of what it may save at linker runtime (we are using
ld.gold, btw).

As I mentioned elsewhere, I am also experimenting with
-Wl,--compress-debug-sections=zlib-gabi, which I think is more or less the same
thing as using 'dwz'. The improvements there are quite nice.

I definitely haven't looked into the combined effects of compresing the debug
info and -fdebug-types-section. It might be interesting to compare the four
combinations.

In any event, -fdebug-types-sections is a documented GCC option that certainly
looks like a good thing to use, so I'd expect at least some projects to use it
in the wild, in which case I think libabigail should be able to tolerate it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20369] Assertion `m' failed in abidw: abg-dwarf-reader.cc:7472

[dodji at seketeli dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #10 from dodji at seketeli dot org ---
"mjw at redhat dot com" <sourceware-bugzilla@sourceware.org> a écrit:

> Compressed ELF section support was added to elfutils 0.165.

Right.  So I am assuming that Andrew is using an elfutils which version
is >= 0.165.

"andrew.c.morrow at gmail dot com"
<sourceware-bugzilla@sourceware.org> a écrit:

> --- Comment #7 from andrew.c.morrow at gmail dot com ---
> I did some further building, and it appears that all of the assertion failures
> reported earlier do not reproduce if -fdebug-types-section is not
> used.

Thanks for the insight, Andrew.  I could reproduce the issue now with
elfutils compiled from the master branch of its Git repository.

I need to look at this more closely, but I am guessing that libabigail's
DWARF reader now needs to support the debug informatin entries of tag
DW_TAG_type_unit (that are emitted when the compiler flag
-fdebug-types-section is emitted) which it doesn't support yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.