[Bug default/28073] New: [libabigail] Incorrect size for bitfields

[Bug default/28073] New: [libabigail] Incorrect size for bitfields

[david.marchand at redhat dot com]

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

            Bug ID: 28073
           Summary: [libabigail] Incorrect size for bitfields
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: david.marchand at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 13555
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13555&action=edit
after_plop.dump

This is a continuation of #28060 with a little extension on the reproducer,
adding a other field at the end of the struct.

$ cat plop.c
#include <inttypes.h>

struct bigstruct {
        char name[128];
        uint8_t bitfield0:1
#ifndef BEFORE
                ,bitfield1:1
#endif
        ;
        uint8_t other;
};

void access_bigstruct(struct bigstruct *st)
{
#ifndef BEFORE
        st->bitfield1 = 1;
#endif
}

XML dump is attached.

As far as I can see, the bitfield0 and bitfield1 are declared with a uint8_t
type, of size 8 bits.
[...]
    <type-decl name='unsigned char' size-in-bits='8' id='type-id-5'/>
[...]
      <data-member access='public' layout-offset-in-bits='7'>
        <var-decl name='bitfield0' type-id='type-id-8' visibility='default'
filepath='/home/dmarchan/libabigail_bitfields/plop.c' line='5' column='1'/>
      </data-member>
      <data-member access='public' layout-offset-in-bits='6'>
        <var-decl name='bitfield1' type-id='type-id-8' visibility='default'
filepath='/home/dmarchan/libabigail_bitfields/plop.c' line='7' column='1'/>
      </data-member>
[...]
    <typedef-decl name='uint8_t' type-id='type-id-9'
filepath='/usr/include/bits/stdint-uintn.h' line='24' column='1'
id='type-id-8'/>
    <typedef-decl name='__uint8_t' type-id='type-id-5'
filepath='/usr/include/bits/types.h' line='38' column='1' id='type-id-9'/>
[...]


This makes it impossible to write a suppression rule based on, for example,
bitfield0 offset.
[suppress_type]
        name = bigstruct
        has_data_member_inserted_between = {offset_after(bitfield0),
offset_of(other)}

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

[Bug default/28073] [libabigail] Incorrect size for bitfields

[dodji at redhat dot com]

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

dodji at redhat dot com changed:

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

--- Comment #1 from dodji at redhat dot com ---
I think the correct suppression specification for this should be:

1/
[suppress_type]
        name = bigstruct
        has_data_member_inserted_between = {offset_of(bitfield0),
offset_of(other)}

Why?

because offset_after(bitfield0) means the offset of the data member that comes
after bitfiled0, in the initial version of the type.  In that version, the data
member that comes after the data member "bitfield0" is the data member "other".

So, {offset_after(bitfield0), offset_of(other)} is equivalent to:
{offset_of(other), offset_of(other)}.  And that is not what we want.

The code that evaluates the suppression specification, however, has a
tangentially related flaw:  If bitfield0 is later removed, the suppression
specification 1/ should not suppress that removal change.  That flaw is now
fixed by the commit
https://sourceware.org/git/?p=libabigail.git;a=commit;h=3e0eeb9f98216ecd1c3224f687fe1e1ef72b56e4
which also updates the documentation of to clarify the use of the
has_data_member_inserted_between property.

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