Bug 19036 - abixml symmetry broken by loss of private attribute
Summary: abixml symmetry broken by loss of private attribute
Status: RESOLVED FIXED
Alias: None
Product: libabigail
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Dodji Seketeli
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-30 23:53 UTC by Ben Woodard
Modified: 2015-10-15 14:34 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
ELF object that reproduces the above problem (1.72 MB, application/x-gzip)
2015-09-30 23:53 UTC, Ben Woodard
Details
Another reproducer (6.12 MB, application/x-bzip2)
2015-10-08 23:05 UTC, Ben Woodard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Woodard 2015-09-30 23:53:03 UTC
Created attachment 8659 [details]
ELF object that reproduces the above problem

hype260@ben:less \\_collab\\_usr\\_global\\_tools\\_order\\_spack\\_opt\\_chaos_5_x86_64_ib\\_gcc\@4.4.7\\_vtk\@6.1.0-2f431570\\_lib\\_libvtkInfovisCore-6.1.so/stderr 
Functions changes summary: 0 Removed, 8 Changed, 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

<snip a bunch of cases of loss of reference see: pr19035>

  [C]'method bool vtkVariant::operator<(const vtkVariant&)' has some indirect sub-type changes:
    'method bool vtkVariant::operator<(const vtkVariant&)' access changed from 'private' to 'public'

The loss of private attribute is something different than I've seen elsewhere.
Comment 1 Ben Woodard 2015-09-30 23:59:08 UTC
In another ELF object it appears that the protected attribute gets dropped in certain cases. I expect that this is just a different manifestation of the same problem. 

hype260@ben:less \\_collab\\_usr\\_global\\_tools\\_order\\_spack\\_opt\\_chaos_5_x86_64_ib\\_gcc\@4.4.7\\_vtk\@6.1.0-2f431570\\_lib\\_libvtkIOParallel-6.1.so/stderr   
Functions changes summary: 0 Removed, 2 Changed, 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

2 functions with some indirect sub-type change:

  [C]'method virtual int vtkPSLACReader::ReadMidpointCoordinates(int, vtkMultiBlockDataSet*, vtkSLACReader::MidpointCoordinateMap&)' has some indirect sub-type changes:
    parameter 3 of type 'vtkSLACReader::MidpointCoordinateMap&' has sub-type changes:
      in referenced type 'class vtkSLACReader::MidpointCoordinateMap':
        'class vtkSLACReader::MidpointCoordinateMap' access changed from 'protected' to 'none'

  [C]'method virtual int vtkPSLACReader::ReadMidpointData(int, vtkMultiBlockDataSet*, vtkSLACReader::MidpointIdMap&)' has some indirect sub-type changes:
    parameter 3 of type 'vtkSLACReader::MidpointIdMap&' has sub-type changes:
      in referenced type 'class vtkSLACReader::MidpointIdMap':
        'class vtkSLACReader::MidpointIdMap' access changed from 'protected' to 'none'
Comment 2 Ben Woodard 2015-10-08 23:05:27 UTC
Created attachment 8695 [details]
Another reproducer

this llvm-as reproducer seems to be a particularly good test case in that it demonstrates a bunch of different problems.
Comment 3 Dodji Seketeli 2015-10-15 14:34:39 UTC
I ran abidw --abidiff on the attached binary, on the master branch at commit https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=09de4435ce4c3d9df2aeda6c0fa615faa2a63bb5, and the problem seems to be gone now.  It has maybe been fixed by some of the recent changes.

Thank you for reporting this problem!