public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/20194] Intel void* idiom has wrong size
Date: Fri, 01 Jan 2016 00:00:00 -0000	[thread overview]
Message-ID: <bug-20194-9487-l6I2cvp15j@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-20194-9487@http.sourceware.org/bugzilla/>

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

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #6 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to Ben Woodard from comment #3)
> As far as I can tell both compilers have valid DWARF and are representing
> the same thing.
> 
> Intel and PGI both say:
> that this is a pointer_type to a subtype.
> that subtype is void which is a base type and which has a length of 0.
> 
> gcc and clang both say:
> this is a pointer type but by omitting the subtype they are implicitly
> saying that the type is void.
> 
> I believe that these are both valid DWARF idioms for expressing "void*"
> libabigail should consider them as equivalent. Right now it doesn't. Instead
> it improperly assumes that the base type is the size for the pointer type.
> 
>   [C]'function void* aligned_alloc(size_t, size_t)' at jemalloc.c:1635:1 has
> some indirect sub-type changes:
>     return type changed:
>       entity changed from 'void*' to 'void'
>       type size changed from 64 to 0 bits
> 
> In the intel case the base type size is 0 but a pointer to a type whose size
> is 0 still is 8 bytes or 64b.

Note that the official way to express this is described in DWARFv4 5.2
Unspecified Type Entries.

"An unspecified (implicit, unknown, ambiguous or nonexistent) type is
represented by a debugging information entry with the tag
DW_TAG_unspecified_type. If a name has been given to the type, then the
corresponding unspecified type entry has a DW_AT_name attribute whose value is
a null-terminated string containing the name as it appears in the source
program.

The interpretation of this debugging information entry is intentionally left
flexible to allow it to be interpreted appropriately in different languages.
For example, in C and C++ the language implementation can provide an
unspecified type entry with the name “void” which can be referenced by the type
attribute of pointer types and typedef declarations for 'void'"

But I agree that any base type with size zero (and "void" name?) could be seen
as equivalent to this (or not specifying a base type).

The only issue is what to do about the specified encoding (signed in this
case). I guess that can also be ignored since it doesn't have any meaning when
the size is zero.

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

      parent reply	other threads:[~2016-07-02 13:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-01  0:00 [Bug default/20194] New: " woodard at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type dodji at redhat dot com
2016-01-01  0:00 ` woodard at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Intel void* idiom has wrong size woodard at redhat dot com
2016-01-01  0:00 ` woodard at redhat dot com
2016-01-01  0:00 ` woodard at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type dodji at redhat dot com
2016-01-01  0:00 ` dodji at redhat dot com
2016-01-01  0:00 ` dodji at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Intel void* idiom has wrong size woodard at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type woodard at redhat dot com
2016-01-01  0:00 ` [Bug default/20194] Intel void* idiom has wrong size woodard at redhat dot com
2016-01-01  0:00 ` woodard at redhat dot com
2016-01-01  0:00 ` mjw at redhat dot com [this message]

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-20194-9487-l6I2cvp15j@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).