[Bug default/20194] Intel void* idiom has wrong size

["mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.