public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "gprocida at google dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/28120] New: abidw: anonymous types and naming typedefs
Date: Thu, 22 Jul 2021 11:16:01 +0000	[thread overview]
Message-ID: <bug-28120-9487@http.sourceware.org/bugzilla/> (raw)

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

            Bug ID: 28120
           Summary: abidw: anonymous types and naming typedefs
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: gprocida at google dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 13563
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13563&action=edit
compressed ABI XML file

Consider this:

typedef struct { int b; } foo;
typedef struct { int b; } bar;
void fun(foo a, bar b) { (void)a; (void)b; }

Compiling results in one type for the struct and two types for the typedefs.
The struct has one naming typedef (and cannot have two, obviously).

We've seen issues with the Linux kernel where isomorphic anonymous structs with
different naming typedefs in different compilation units end up as the same
type id in the XML, but appear twice with different naming typedef ids.

The attachment illustrates the issue with type id 8425539a. In terms of ABI
diffing this is probably a low priority issue - I don't think naming typedef is
even inspected.

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

                 reply	other threads:[~2021-07-22 11:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-28120-9487@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=libabigail@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).