Re: [Bug default/19707] New: Weird report for subtype change and "no data member change"

Re: [Bug default/19707] New: Weird report for subtype change and "no data member change"

[Dodji Seketeli]

Hello,

> The other puzzling thing is this:
>
>   [C]'method unity::scopes::ActivationQueryBase::ActivationQueryBase(const
> unity::scopes::Result&, const unity::scopes::ActionMetadata&)' at
> ActivationQueryBase.cpp:29:1 has some indirect sub-type changes:
>     parameter 1 of type 'const unity::scopes::Result&' has sub-type changes:
>       in referenced type 'const unity::scopes::Result':
>         in unqualified underlying type 'class unity::scopes::Result' at
> Result.h:50:1:
>           no data member change (1 filtered);

I believe this is a bug.  The comparison engine noticed a change that
was later flagged as "non serious" on a data member of
unity::scope::Result.  And thus, that change was filtered out.  But
then, as this is the only sub-type change seen on the function
ActivationQueryBase::ActivationQueryBase() (and as this only change got
filtered out) the entire change report on that function should have been
filtered out.

In other words, in libabigail parlance, I believe this is a
categorization propagation bug.


-- 
		Dodji

[Bug default/19707] Weird report for subtype change and "no data member change"

[michi.henning at canonical dot com]

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

--- Comment #3 from Michi Henning <michi.henning at canonical dot com> ---
(In reply to dodji from comment #2)

> At first glance it looks like this function was inlined completely in
> the base dump, and not in the later one.

Yes, that seems likely, seeing that the base dump was compiled with -O2, and
the later dump wasn't

> I'd need the binaries to be sure.  Not just the dumps.

I'll upload binaries tomorrow!

Ideally, I would love to be able to use the current lib whether it was compiled
with -g or compiled with -g -O2. (The base dump always comes from a lib that
was compiled with -g -O2.) If this is possible, it would make day-to-day
testing a lot easier. If it's not possible, so be it. (But being able to tell
at least would be still be useful, so we can print an appropriate warning.)

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

[Bug default/19707] Weird report for subtype change and "no data member change"

[dodji at seketeli dot org]

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

--- Comment #1 from dodji at seketeli dot org ---
Hello,

> The other puzzling thing is this:
>
>   [C]'method unity::scopes::ActivationQueryBase::ActivationQueryBase(const
> unity::scopes::Result&, const unity::scopes::ActionMetadata&)' at
> ActivationQueryBase.cpp:29:1 has some indirect sub-type changes:
>     parameter 1 of type 'const unity::scopes::Result&' has sub-type changes:
>       in referenced type 'const unity::scopes::Result':
>         in unqualified underlying type 'class unity::scopes::Result' at
> Result.h:50:1:
>           no data member change (1 filtered);

I believe this is a bug.  The comparison engine noticed a change that
was later flagged as "non serious" on a data member of
unity::scope::Result.  And thus, that change was filtered out.  But
then, as this is the only sub-type change seen on the function
ActivationQueryBase::ActivationQueryBase() (and as this only change got
filtered out) the entire change report on that function should have been
filtered out.

In other words, in libabigail parlance, I believe this is a
categorization propagation bug.

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

[Bug default/19707] Weird report for subtype change and "no data member change"

[dodji at seketeli dot org]

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

--- Comment #2 from dodji at seketeli dot org ---
"michi.henning at canonical dot com"
<sourceware-bugzilla@sourceware.org> a écrit:


> method virtual void unity::scopes::ScopeBase::stop() didn't have any linkage
> name, and it now has: '_ZN5unity6scopes9ScopeBase4stopEv'

At first glance it looks like this function was inlined completely in
the base dump, and not in the later one.

I'd need the binaries to be sure.  Not just the dumps.

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

[Bug default/19707] Weird report for subtype change and "no data member change"

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

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

--- Comment #5 from dodji at redhat dot com ---
This issue should be fixed in the master branch of the git repository by commit
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=2bbe75a08a951b1536e134808fe8396152fdf0c4.

Note that using the suppression specification provided to me offline, on the
binaries provided, I get a report in which there is *NO* function with sub-type
change left.

Thank you for taking the time to file this problem report and for your on-going
assistance.

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

[Bug default/19707] Weird report for subtype change and "no data member change"

[dodji at redhat dot com]

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

--- Comment #4 from dodji at redhat dot com ---
(In reply to dodji from comment #2)
> > method virtual void unity::scopes::ScopeBase::stop() didn't have any linkage
> > name, and it now has: '_ZN5unity6scopes9ScopeBase4stopEv'
> 
> At first glance it looks like this function was inlined completely in
> the base dump, and not in the later one.

I was wrong here.  Thanks to the binaries you gave me offline, I could look
into this.

The reason why we are seeing this is because in the optimized binary, the DIE
for unity::scopes::ScopeBase::stop() has linkage name (I need to change that
change report), but has no underlying elf symbol set.  The elf symbol exists in
the binary, though.  There is just no attribute on the DIE of the function that
points to the elf symbol.

In the non optimized binary, though, the DIE of that function properly points
to the elf symbol.

I didn't expect such a construct in the debug info.

I'll post a patch for this soon.

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

[Bug default/19707] New: Weird report for subtype change and "no data member change"

[michi.henning at canonical dot com]

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

            Bug ID: 19707
           Summary: Weird report for subtype change and "no data member
                    change"
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: michi.henning at canonical dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

I'm using the same dumps as for bug 19706 (abigail compiled from HEAD).

Here are the suppressions:

[suppress_function]
    name_regexp = boost::.*
    change_kind = all
    allow_other_aliases = false

[suppress_function]
    name_regexp = std::.*
    change_kind = all
    allow_other_aliases = false

[suppress_function]
    name_regexp = unity::scopes::testing::.*
    change_kind = all
    allow_other_aliases = false

[suppress_function]
    name_regexp = unity::scopes::internal::.*
    change_kind = all
    allow_other_aliases = false

I've attached the report output. There are two things I find puzzling:

method virtual void unity::scopes::ScopeBase::stop() didn't have any linkage
name, and it now has: '_ZN5unity6scopes9ScopeBase4stopEv'

I suspect that this is happening because the base dump was produced with -g
-O2, but the current dump with -g.

When I compile the current ABI with -g -O2, this particular item goes away. Is
it possible to handle this better?

The other puzzling thing is this:

  [C]'method unity::scopes::ActivationQueryBase::ActivationQueryBase(const
unity::scopes::Result&, const unity::scopes::ActionMetadata&)' at
ActivationQueryBase.cpp:29:1 has some indirect sub-type changes:
    parameter 1 of type 'const unity::scopes::Result&' has sub-type changes:
      in referenced type 'const unity::scopes::Result':
        in unqualified underlying type 'class unity::scopes::Result' at
Result.h:50:1:
          no data member change (1 filtered);

This happens whether I compile the current ABI with -g or with -g -O2.
What is it trying to tell me here?

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

Re: [Bug default/19707] New: Weird report for subtype change and "no data member change"

[Dodji Seketeli]

"michi.henning at canonical dot com"
<sourceware-bugzilla@sourceware.org> a écrit:


> method virtual void unity::scopes::ScopeBase::stop() didn't have any linkage
> name, and it now has: '_ZN5unity6scopes9ScopeBase4stopEv'

At first glance it looks like this function was inlined completely in
the base dump, and not in the later one.

I'd need the binaries to be sure.  Not just the dumps.

-- 
		Dodji

[Bug default/19707] Weird report for subtype change and "no data member change"

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

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

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