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

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

[woodard at redhat dot com]

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

            Bug ID: 20194
           Summary: Intel void* idiom has wrong size
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 9306
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9306&action=edit
Intel compiled object

[C]'function void* _elf_mmap(Elf*)' at input.c:87:1 has some indirect sub-type
changes:
    return type changed:
      entity changed from 'void*' to 'void'
      type size changed from 64 to 0 bits

GCC
 <1><1dc71>: Abbrev Number: 29 (DW_TAG_subprogram)
    <1dc72>   DW_AT_external    : 1
    <1dc72>   DW_AT_name        : (indirect string, offset: 0xa0a): _elf_mmap
    <1dc76>   DW_AT_decl_file   : 1
    <1dc77>   DW_AT_decl_line   : 87
    <1dc78>   DW_AT_prototyped  : 1
    <1dc78>   DW_AT_type        : <0x1d2f2>
    <1dc7c>   DW_AT_low_pc      : 0xab80
    <1dc84>   DW_AT_high_pc     : 0x63 0x0
    <1dc8c>   DW_AT_frame_base  : 1 byte block: 9c      (DW_OP_call_frame_cfa)
    <1dc8e>   Unknown AT value: 2117: 1
    <1dc8e>   DW_AT_sibling     : <0x1dcd3>

 <1><1d2f2>: Abbrev Number: 5 (DW_TAG_pointer_type)
    <1d2f3>   DW_AT_byte_size   : 8

Intel:
 <1><1532e>: Abbrev Number: 6 (DW_TAG_subprogram)
    <1532f>   DW_AT_decl_line   : 87
    <15330>   DW_AT_decl_file   : 1
    <15331>   DW_AT_type        : <0x14ac4>
    <15335>   DW_AT_prototyped  : 1
    <15336>   DW_AT_name        : (indirect string, offset: 0x11b2): _elf_mmap
    <1533a>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x11b2):
_elf_mmap
    <1533e>   DW_AT_low_pc      : 0xebd0
    <15346>   DW_AT_high_pc     : 0xec20
    <1534e>   DW_AT_external    : 1

 <1><14ac4>: Abbrev Number: 2 (DW_TAG_pointer_type)
    <14ac5>   DW_AT_type        : <0x14ac9>
 <1><14ac9>: Abbrev Number: 3 (DW_TAG_base_type)
    <14aca>   DW_AT_byte_size   : 0
    <14acb>   DW_AT_encoding    : 5     (signed)
    <14acc>   DW_AT_name        : (indirect string, offset: 0x2cf): void

This one looks to me sort of like a libabigail bug but I'm not versed enough
with DWARF to know for sure.

It looks to me like the idiom for a void* in GCC is a pointer type with no
type. On the other hand Intel points to a the base type which is void and has a
zero length. Can you assume that any pointer is 8 due to the architecture or
something else in the DWARF? Right now it looks to me like libabigail is using
the size of the base_type in place of the assumed size of a pointer.

The next error that I started to look into seems related:

  [C]'function void* _elf_read(Elf*, void*, size_t, size_t)' at input.c:56:1
has some indirect sub-\
type changes:
    parameter 2 of type 'void*' changed:
      entity changed from 'void*' to 'typedef size_t' at stddef.h:44:1
    parameter 4 of type 'typedef size_t' was removed

When you look at how intel describes it, 

<1><14af2>: Abbrev Number: 6 (DW_TAG_subprogram)
    <14af3>   DW_AT_decl_line   : 56
    <14af4>   DW_AT_decl_file   : 1
    <14af5>   DW_AT_type        : <0x14ac4>
    <14af9>   DW_AT_prototyped  : 1
    <14afa>   DW_AT_name        : (indirect string, offset: 0x11a2): _elf_read
    <14afe>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x11a2):
_elf_read
    <14b02>   DW_AT_low_pc      : 0xeaa0
    <14b0a>   DW_AT_high_pc     : 0xebd0
    <14b12>   DW_AT_external    : 1
 <2><14b13>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <14b14>   DW_AT_decl_line   : 56
    <14b15>   DW_AT_decl_file   : 1
    <14b16>   DW_AT_type        : <0x14ba8>
    <14b1a>   DW_AT_name        : elf
    <14b1e>   DW_AT_location    : 1 byte block: 55      (DW_OP_reg5)
 <2><14b20>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <14b21>   DW_AT_decl_line   : 56
    <14b22>   DW_AT_decl_file   : 1
    <14b23>   DW_AT_type        : <0x14ac4>
    <14b27>   DW_AT_name        : (indirect string, offset: 0x994): buffer
    <14b2b>   DW_AT_location    : 1 byte block: 54      (DW_OP_reg4)
 <2><14b2d>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <14b2e>   DW_AT_decl_line   : 56
    <14b2f>   DW_AT_decl_file   : 1
    <14b30>   DW_AT_type        : <0x14dff>
    <14b34>   DW_AT_name        : off
    <14b38>   DW_AT_location    : 1 byte block: 51      (DW_OP_reg1)
 <2><14b3a>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <14b3b>   DW_AT_decl_line   : 56
    <14b3c>   DW_AT_decl_file   : 1
    <14b3d>   DW_AT_type        : <0x14dff>
    <14b41>   DW_AT_name        : len
    <14b45>   DW_AT_location    : 1 byte block: 52      (DW_OP_reg2)

it looks like libabigail is tripping over the void* in the middle which points
back to our old friend 14ac4 the idiomatically defined void*. However, once you
get past that it looks like the abi is the same.

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

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[dodji at redhat dot com]

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

--- Comment #9 from dodji at redhat dot com ---
"woodard at redhat dot com" <sourceware-bugzilla@sourceware.org> writes:

So it seems this is a different issue.  The debug info is talking about
a pointer to "const void" type.  And I guess we can safely reduce the
"const void" type into an equivalent "void" type.

I'd like to have the offending binaries (the one that says "const void"
and the one that just say 'void') to see how the abi changes are
reported.  If the binaries are small enough, I'd like to add them to the
libabigail regression test suite, when I come up with a proper fix.

Also, when we have the binaries, then can open a different enhancement
request to specifically track the feature of reducing this "const void"
into just a "void" type, I guess.

Thanks.

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

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

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

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

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1
           Severity|normal                      |critical

--- Comment #4 from Ben Woodard <woodard at redhat dot com> ---
I'm moving this up to P1 and critical. This particular problem seems to at the
root of most of the problems that I'm currently seeing and the additional noise
when trying to analyze the output makes finding new problems much more
difficult and time consuming.

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

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

[woodard at redhat dot com]

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

--- Comment #3 from Ben Woodard <woodard at redhat dot com> ---
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.

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

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

[woodard at redhat dot com]

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

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 9317
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9317&action=edit
pgi compiled object

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

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[woodard at redhat dot com]

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

--- Comment #10 from Ben Woodard <woodard at redhat dot com> ---
These are the binaries that are attached to 20323 in the tarball. I would argue
that this is a compiler bug because there is no mention of const in the
original source code so that const comes out of thin air. So if you feel like
this is better handled with a suppression that sounds fine to me.

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

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from dodji at redhat dot com ---
A fix for this issue has been committed to the master branch of the git
repository at
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=10ce99e428e03c30197bfd22e48f0799e8a99db9.

Thanks for reporting this problem!

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

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

[mjw at redhat dot com]

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.

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

[woodard at redhat dot com]

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

--- Comment #5 from Ben Woodard <woodard at redhat dot com> ---
other manifestations:

  [C]'function void free(void*)' at jemalloc.c:1915:1 has some indirect
sub-type changes:
    parameter 1 of type 'void*' was removed

  [C]'function void free(void*)' at jemalloc.c:1915:1 has some indirect
sub-type changes:
    parameter 1 of type 'void*' was removed


  [C]'function int mallctl(const char*, void*, size_t*, void*, size_t)' at
jemalloc.c:2554:1 has some indirect sub-type changes:
    parameter 2 of type 'void*' changed:
      in pointed to type 'void' at stddef.h:44:1:
        entity changed from 'void' to compatible type 'typedef size_t' at
stddef.h:44:1
          type name changed from 'void' to 'unsigned long'
          type size changed from 0 to 64 bits
    parameter 3 of type 'size_t*' changed:
      entity changed from 'size_t*' to 'typedef size_t' at stddef.h:44:1
    parameter 4 of type 'void*' was removed
    parameter 5 of type 'typedef size_t' was removed


  [C]'function int mallctlbymib(const size_t*, size_t, void*, size_t*, void*,
size_t)' at jemalloc.c:2575:1 has some indirect sub-type changes:
    parameter 4 of type 'size_t*' changed:
      entity changed from 'size_t*' to 'typedef size_t' at stddef.h:44:1
    parameter 5 of type 'void*' was removed
    parameter 6 of type 'typedef size_t' was removed


  [C]'function void malloc_stats_print(void (void*, const char*)*, void*, const
char*)' at jemalloc.c:2586:1 has some indirect sub-type changes:
    parameter 1 of type 'void (void*, const char*)*' changed:
      in pointed to type 'function type void (void*, const char*)':
        parameter 2 of type 'const char*' was removed

    parameter 2 of type 'void*' changed:
      in pointed to type 'void':
        entity changed from 'void' to 'const char'
        type size changed from 0 to 8 bits
    parameter 3 of type 'const char*' was removed


  [C]'function size_t malloc_usable_size(void*)' at jemalloc.c:2594:1 has some
indirect sub-type changes:
    parameter 1 of type 'void*' was removed


  [C]'function int posix_memalign(void**, size_t, size_t)' at jemalloc.c:1624:1
has some indirect sub-type changes:
    parameter 1 of type 'void**' changed:
      entity changed from 'void**' to 'typedef size_t' at stddef.h:44:1
    parameter 3 of type 'typedef size_t' was removed


  [C]'function void* rallocx(void*, size_t, int)' at jemalloc.c:2251:1 has some
indirect sub-type changes:
    parameter 1 of type 'void*' changed:
      entity changed from 'void*' to 'typedef size_t' at stddef.h:44:1
    parameter 2 of type 'typedef size_t' changed:
      entity changed from 'typedef size_t' to compatible type 'int'
        type name changed from 'long unsigned int' to 'int'
        type size changed from 64 to 32 bits
    parameter 3 of type 'int' was removed


  [C]'function void* realloc(void*, size_t)' at jemalloc.c:1849:1 has some
indirect sub-type changes:
    parameter 2 of type 'typedef size_t' was removed


  [C]'function void sdallocx(void*, size_t, int)' at jemalloc.c:2511:1 has some
indirect sub-type changes:
    parameter 3 of type 'int' was removed


  [C]'function size_t xallocx(void*, size_t, size_t, int)' at jemalloc.c:2402:1
has some indirect sub-type changes:
    parameter 3 of type 'typedef size_t' changed:
      entity changed from 'typedef size_t' to compatible type 'int'
    parameter 4 of type 'int' was removed

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

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

[woodard at redhat dot com]

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

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |20323


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=20323
[Bug 20323] void* idiom for intel, PGI DWARF confuses subsequent parameter
handling
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[woodard at redhat dot com]

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

--- Comment #8 from Ben Woodard <woodard at redhat dot com> ---
Much improved!!!

But there still seems to be a much rarer corner case with intel.

 13953]    subprogram
             decl_line            (data2) 2594
             decl_column          (data1) 1
             decl_file            (data1) 20
             type                 (ref4) [   505]
             prototyped           (flag)
             name                 (strp) "malloc_usable_size"
             MIPS_linkage_name    (strp) "malloc_usable_size"
             low_pc               (addr) +0x000000000000c1d0
<malloc_usable_size>
             high_pc              (addr) +0x000000000000c340
<jemalloc_constructor>
             external             (flag)
 [ 13976]      formal_parameter
               decl_line            (data2) 2594
               decl_column          (data1) 56
               decl_file            (data1) 20
               type                 (ref4) [   52f]
               name                 (string) "ptr"
               location             (block1)
                [   0] reg5


 [   52f]    pointer_type
             type                 (ref4) [   534]
 [   534]    const_type
             type                 (ref4) [   539]
 [   539]    base_type
             byte_size            (data1) 0
             encoding             (data1) signed (5)
             name                 (strp) "void"

Arguably this is a compiler bug with Intel and that should be considered I
think. There is nothing in the source code that suggests any sort of const-ness
and so the fact that the compiler inserts it here in the type for the parameter
is incorrect.

However, should we consider that to be an ABI relevant artifact?
I can go either way on that. I will be happy to submit a bug to intel regarding
this.

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

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

[woodard at redhat dot com]

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

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 9307
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9307&action=edit
gcc compiled object

by doing an abidiff between these two objects you can see the errors mentioned
above.

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

[Bug default/20194] Fail to recognize void type represented by DW_TAG_base_type

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Intel void* idiom has wrong |Fail to recognize void type
                   |size                        |represented by
                   |                            |DW_TAG_base_type

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