[Bug default/25042] New: abidw aborts on clang compiled gdbm shared library

[Bug default/25042] New: abidw aborts on clang compiled gdbm shared library

[woodard at redhat dot com]

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

            Bug ID: 25042
           Summary: abidw aborts on clang compiled gdbm shared library
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 12007
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12007&action=edit
problematic file

current libabigail built from trunk as of
4fba6bea177ffa1981b8252f7f1967814b3ecf94 crashes on the attached binary.

$ ~/tmp/test/bin/abidw
./opt/spack/linux-fedora30-x86_64/clang-8.0.0.O0/gdbm-1.18.1-4l6xjbu74zu2aqu7gwrf3xzfcyun4abo/lib/libgdbm.so.6.0.0 
abidw: ../../src/abg-dwarf-reader.cc:10605: bool
abigail::dwarf_reader::compare_dies_string_attribute_value(const Dwarf_Die*,
const Dwarf_Die*, unsigned int, bool&): Assertion `__abg_cond__' failed.
Aborted (core dumped)

The cflags were: -g3 -gdwarf-5 -O0 my guess is that it has something to do with
the DWARF5. I'll do a build using -gdwarf-4 for comparison.

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

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

--- Comment #6 from dodji at redhat dot com ---
Closing this thus.

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[dodji at redhat dot com]

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

--- Comment #4 from dodji at redhat dot com ---
"mark at klomp dot org" <sourceware-bugzilla@sourceware.org> writes:

> I see compare_dies_string_attribute_value () does, so it can do a pointer
> comparison instead of doing a full string comparison.

[...]

Right we really need that optimization because we do type de-duplication
at the DWARF level. 

> How much "speedup" do you get from that "optimization"?

String comparisons dominates the profile when doing type de-duplication.
I don't recall the speed-up right now (I've worked on tons of speed
optimizations left and right, all guided by careful profiling), but
suffice it to say that the string comparison was absolutely necessary to
make the speed of the de-duplication (at the DWARF level) be acceptable
at the time.  The de-duplication itself being a major size optimization.

This is of course in the context of huge C binaries like the linux
kernel.  I haven't implemented this for C++ binaries yet, but at some
point I think it'll be necessary to look into it as we still have bugs
open about libabigail being slow on huge C++ binaries.

> But I think the logic there is broken, especially when dealing with
> split-dwarf DWO files.

Well, libabigail doesn't yet support DWO files, so I wouldn't worry
about that at this point.

When we do support split-dwarf DWO files, then my understanding is that
type de-duplication would then be un-necessary because the
de-duplication would have been done by the DWARF emitter already, by
construction.  At that point, this optimization will be unnecessary,
hopefully.

But until then and for all the cases where we need to support non-DWO
files, I think this optimization will be necessary.  Anyhow, this
comparison speed-up is encapsulated at one place so when it becomes
unnecessary, it's easy to do away with.

So should we really worry about this?

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from dodji at redhat dot com ---
Ah, this looks like we need to support the DWARF forms DW_FORM_strx{1,4} from
DWARF5.

I am on it.

Thanks for reporting this!

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[dodji at redhat dot com]

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

--- Comment #5 from dodji at redhat dot com ---
This should now be fixed by commits
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=568dee18a1358e79047e94d10f7eee6f4632464c
and
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=1f53d1faa90f119d946f6fc7db9c09c2af767cb5.

The fix should be available in the upcoming 1.7 release of Libabigail.

Thank you for filling this issue.

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[woodard at redhat dot com]

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

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
It is confirmed that the dwarf-4 version doesn't crash abidw.

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

[Bug default/25042] abidw aborts on clang compiled gdbm shared library

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
Note that elfutils libdw should already handle DW_FORM_strx forms since 0.171.

In general you shouldn't need to handle/check the actual DW_FORM an attribute
is encoded with.

I see compare_dies_string_attribute_value () does, so it can do a pointer
comparison instead of doing a full string comparison. But I think the logic
there is broken, especially when dealing with split-dwarf DWO files.

How much "speedup" do you get from that "optimization"?

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