Bug 28675 - whitespace in DWARF template naming confuses libabigail.
Summary: whitespace in DWARF template naming confuses libabigail.
Status: NEW
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: 27019
  Show dependency treegraph
 
Reported: 2021-12-08 23:44 UTC by Ben Woodard
Modified: 2021-12-09 00:10 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Woodard 2021-12-08 23:44:04 UTC
Comparing gcc built libabigail.so.0 to llvm built libabigail.so.0 one of the commonly reported differences is like this:

  [C] 'method const std::vector<abigail::comparison::diff*, std::allocator<abigail::comparison::diff*> >& abigail::comparison::corpus_diff::children_nodes() const' at abg-comparison.h:2325:1 has some indirect sub-type changes:
    return type changed:
      in referenced type 'const std::vector<abigail::comparison::diff*, std::allocator<abigail::comparison::diff*> >':
        'const std::vector<abigail::comparison::diff*, std::allocator<abigail::comparison::diff*> >' changed to 'const std::vector<abigail::comparison::diff *, std::allocator<abigail::comparison::diff *> >'

The difference is nothing other than white space:
const std::vector<abigail::comparison::diff*, std::allocator<abigail::comparison::diff*> >
const std::vector<abigail::comparison::diff *, std::allocator<abigail::comparison::diff *> >

clang puts a space between typename and the * while GCC does not.

This should be a special case that is handled by libabigail. It is not an actual ABI difference.
Comment 1 Ben Woodard 2021-12-09 00:10:28 UTC
This may be a duplicate of 28664 depending on how you frame it. In 28664 it has to do with the template value parameter type. In this case it is the representation of certain template type parameter.

One way of considering the bugs is that both have to do with string comparison of the template typename vs. drilling down into the types being instantiated by the template. In that case they may be the same bug.