mbox series

[00/16] support __packed struct

Message ID 20201226175129.9621-1-luc.vanoostenryck@gmail.com (mailing list archive)
Headers show
Series support __packed struct | expand

Message

Luc Van Oostenryck Dec. 26, 2020, 5:51 p.m. UTC
During parsing, Sparse recognizes the attribute 'packed' but this
attribute is otherwise ignored for several reasons:
1) the attribute in 'struct __attr { ... }' is wrongly handled as
   belonging to the whole declaration but it should belong to the type,
2) the attribute in 'struct <name> { ... } __attr;' is simply ignored,
3) the layout of packed bitfields need special care.

This series contains 2 parts:
1) handling of type attributes
2) correct layout of packed structs, including packed bitfields.


This series is also available for review and testing at:
  git://git.kernel.org/pub/scm/devel/sparse/sparse-dev.git packed-v2


Changes since v1:
* fix layout of packed bitfields

Luc Van Oostenryck (16):
  add testcases for dubious enum values
  add testcases for exotic enum values
  add testcases for enum attributes
  add testcases for type attributes
  add testcases for packed structures
  add testcases for packed bitfields
  apply_ctype: use self-explanatory argument name
  apply_ctype: reverse the order of arguments
  apply_ctype: move up its declaration
  struct-attr: prepare to handle attributes at the end of struct definitions (1)
  struct-attr: prepare to handle attributes at the end of struct definitions (2)
  struct-attr: prepare to handle attributes at the end of struct definitions (3)
  struct-attr: fix type attribute like 'struct __attr { ... }'
  struct-attr: fix: do not ignore struct/union/enum type attributes
  packed: no out-of-bound access of packed bitfields
  packed: add support for __packed struct

 linearize.c                       | 13 +++++-
 parse.c                           | 71 ++++++++++++++++---------------
 symbol.c                          | 12 ++++--
 symbol.h                          |  2 +
 validation/enum-type-dubious.c    | 18 ++++++++
 validation/enum-type-exotic.c     | 28 ++++++++++++
 validation/packed-bitfield0.c     | 66 ++++++++++++++++++++++++++++
 validation/packed-bitfield1.c     | 27 ++++++++++++
 validation/packed-bitfield2.c     | 15 +++++++
 validation/packed-bitfield3.c     | 28 ++++++++++++
 validation/packed-bitfield4.c     | 18 ++++++++
 validation/packed-bitfield5.c     | 20 +++++++++
 validation/packed-deref0.c        | 23 ++++++++++
 validation/packed-struct.c        | 32 ++++++++++++++
 validation/parsing/enum-attr.c    | 29 +++++++++++++
 validation/type-attribute-align.c | 19 +++++++++
 validation/type-attribute-as.c    | 33 ++++++++++++++
 validation/type-attribute-mod.c   | 21 +++++++++
 validation/type-attribute-qual.c  | 12 ++++++
 19 files changed, 448 insertions(+), 39 deletions(-)
 create mode 100644 validation/enum-type-dubious.c
 create mode 100644 validation/enum-type-exotic.c
 create mode 100644 validation/packed-bitfield0.c
 create mode 100644 validation/packed-bitfield1.c
 create mode 100644 validation/packed-bitfield2.c
 create mode 100644 validation/packed-bitfield3.c
 create mode 100644 validation/packed-bitfield4.c
 create mode 100644 validation/packed-bitfield5.c
 create mode 100644 validation/packed-deref0.c
 create mode 100644 validation/packed-struct.c
 create mode 100644 validation/parsing/enum-attr.c
 create mode 100644 validation/type-attribute-align.c
 create mode 100644 validation/type-attribute-as.c
 create mode 100644 validation/type-attribute-mod.c
 create mode 100644 validation/type-attribute-qual.c


base-commit: 1b896707d95982c7c9cdd5cd0ab4afd80f766a94
Cc: Jacob Keller <jacob.e.keller@intel.com>

Comments

Ramsay Jones Dec. 28, 2020, 5:18 p.m. UTC | #1
On 26/12/2020 17:51, Luc Van Oostenryck wrote:
> During parsing, Sparse recognizes the attribute 'packed' but this
> attribute is otherwise ignored for several reasons:
> 1) the attribute in 'struct __attr { ... }' is wrongly handled as
>    belonging to the whole declaration but it should belong to the type,
> 2) the attribute in 'struct <name> { ... } __attr;' is simply ignored,
> 3) the layout of packed bitfields need special care.
> 
> This series contains 2 parts:
> 1) handling of type attributes
> 2) correct layout of packed structs, including packed bitfields.
> 
> 
> This series is also available for review and testing at:
>   git://git.kernel.org/pub/scm/devel/sparse/sparse-dev.git packed-v2

I left a couple of minor comments, but (apart from patch #16) this
otherwise LGTM.

Patch #16 also looks good, but I would need to study it a bit more
than I have time available to be totally happy. It does not seem
to be handling the 'lowering' of 'odd bit-sized' symbols created in
the previous patch (to answer my own question), so I would have to
apply the patches (or fetch the above branch) to study some more.

Hope you had a good holiday.

ATB,
Ramsay Jones
Luc Van Oostenryck Dec. 28, 2020, 9:33 p.m. UTC | #2
On Mon, Dec 28, 2020 at 05:18:50PM +0000, Ramsay Jones wrote:
> 
> 
> On 26/12/2020 17:51, Luc Van Oostenryck wrote:
> > During parsing, Sparse recognizes the attribute 'packed' but this
> > attribute is otherwise ignored for several reasons:
> > 1) the attribute in 'struct __attr { ... }' is wrongly handled as
> >    belonging to the whole declaration but it should belong to the type,
> > 2) the attribute in 'struct <name> { ... } __attr;' is simply ignored,
> > 3) the layout of packed bitfields need special care.
> > 
> > This series contains 2 parts:
> > 1) handling of type attributes
> > 2) correct layout of packed structs, including packed bitfields.
> > 
> > 
> > This series is also available for review and testing at:
> >   git://git.kernel.org/pub/scm/devel/sparse/sparse-dev.git packed-v2
> 
> I left a couple of minor comments, but (apart from patch #16) this
> otherwise LGTM.
> 
> Patch #16 also looks good, but I would need to study it a bit more
> than I have time available to be totally happy. It does not seem
> to be handling the 'lowering' of 'odd bit-sized' symbols created in
> the previous patch (to answer my own question), so I would have to
> apply the patches (or fetch the above branch) to study some more.

Well, patch #16 doesn't contain the lowering, it kinda just enables
the last bits to support (without out-of-bound access) packed structures
including packed bitfields.

> Hope you had a good holiday.

Thank you. In truth, it was strange and quiet, very quiet.

I wish you all the best for 2021!

-- Luc
Jacob Keller Jan. 5, 2021, 5:55 p.m. UTC | #3
On 12/26/2020 9:51 AM, Luc Van Oostenryck wrote:
> During parsing, Sparse recognizes the attribute 'packed' but this
> attribute is otherwise ignored for several reasons:
> 1) the attribute in 'struct __attr { ... }' is wrongly handled as
>    belonging to the whole declaration but it should belong to the type,
> 2) the attribute in 'struct <name> { ... } __attr;' is simply ignored,
> 3) the layout of packed bitfields need special care.
> 
> This series contains 2 parts:
> 1) handling of type attributes
> 2) correct layout of packed structs, including packed bitfields.
> 
> 
> This series is also available for review and testing at:
>   git://git.kernel.org/pub/scm/devel/sparse/sparse-dev.git packed-v2
> 

This series looks good to me, and it resolves the issues I saw a few
weeks ago with size.

Thanks,
Jake

> 
> Changes since v1:
> * fix layout of packed bitfields
> 
> Luc Van Oostenryck (16):
>   add testcases for dubious enum values
>   add testcases for exotic enum values
>   add testcases for enum attributes
>   add testcases for type attributes
>   add testcases for packed structures
>   add testcases for packed bitfields
>   apply_ctype: use self-explanatory argument name
>   apply_ctype: reverse the order of arguments
>   apply_ctype: move up its declaration
>   struct-attr: prepare to handle attributes at the end of struct definitions (1)
>   struct-attr: prepare to handle attributes at the end of struct definitions (2)
>   struct-attr: prepare to handle attributes at the end of struct definitions (3)
>   struct-attr: fix type attribute like 'struct __attr { ... }'
>   struct-attr: fix: do not ignore struct/union/enum type attributes
>   packed: no out-of-bound access of packed bitfields
>   packed: add support for __packed struct
> 
>  linearize.c                       | 13 +++++-
>  parse.c                           | 71 ++++++++++++++++---------------
>  symbol.c                          | 12 ++++--
>  symbol.h                          |  2 +
>  validation/enum-type-dubious.c    | 18 ++++++++
>  validation/enum-type-exotic.c     | 28 ++++++++++++
>  validation/packed-bitfield0.c     | 66 ++++++++++++++++++++++++++++
>  validation/packed-bitfield1.c     | 27 ++++++++++++
>  validation/packed-bitfield2.c     | 15 +++++++
>  validation/packed-bitfield3.c     | 28 ++++++++++++
>  validation/packed-bitfield4.c     | 18 ++++++++
>  validation/packed-bitfield5.c     | 20 +++++++++
>  validation/packed-deref0.c        | 23 ++++++++++
>  validation/packed-struct.c        | 32 ++++++++++++++
>  validation/parsing/enum-attr.c    | 29 +++++++++++++
>  validation/type-attribute-align.c | 19 +++++++++
>  validation/type-attribute-as.c    | 33 ++++++++++++++
>  validation/type-attribute-mod.c   | 21 +++++++++
>  validation/type-attribute-qual.c  | 12 ++++++
>  19 files changed, 448 insertions(+), 39 deletions(-)
>  create mode 100644 validation/enum-type-dubious.c
>  create mode 100644 validation/enum-type-exotic.c
>  create mode 100644 validation/packed-bitfield0.c
>  create mode 100644 validation/packed-bitfield1.c
>  create mode 100644 validation/packed-bitfield2.c
>  create mode 100644 validation/packed-bitfield3.c
>  create mode 100644 validation/packed-bitfield4.c
>  create mode 100644 validation/packed-bitfield5.c
>  create mode 100644 validation/packed-deref0.c
>  create mode 100644 validation/packed-struct.c
>  create mode 100644 validation/parsing/enum-attr.c
>  create mode 100644 validation/type-attribute-align.c
>  create mode 100644 validation/type-attribute-as.c
>  create mode 100644 validation/type-attribute-mod.c
>  create mode 100644 validation/type-attribute-qual.c
> 
> 
> base-commit: 1b896707d95982c7c9cdd5cd0ab4afd80f766a94
> Cc: Jacob Keller <jacob.e.keller@intel.com>
>
Jacob Keller Jan. 5, 2021, 5:56 p.m. UTC | #4
On 12/28/2020 1:33 PM, Luc Van Oostenryck wrote:
> On Mon, Dec 28, 2020 at 05:18:50PM +0000, Ramsay Jones wrote:
>>
>>
>> On 26/12/2020 17:51, Luc Van Oostenryck wrote:
>>> During parsing, Sparse recognizes the attribute 'packed' but this
>>> attribute is otherwise ignored for several reasons:
>>> 1) the attribute in 'struct __attr { ... }' is wrongly handled as
>>>    belonging to the whole declaration but it should belong to the type,
>>> 2) the attribute in 'struct <name> { ... } __attr;' is simply ignored,
>>> 3) the layout of packed bitfields need special care.
>>>
>>> This series contains 2 parts:
>>> 1) handling of type attributes
>>> 2) correct layout of packed structs, including packed bitfields.
>>>
>>>
>>> This series is also available for review and testing at:
>>>   git://git.kernel.org/pub/scm/devel/sparse/sparse-dev.git packed-v2
>>
>> I left a couple of minor comments, but (apart from patch #16) this
>> otherwise LGTM.
>>
>> Patch #16 also looks good, but I would need to study it a bit more
>> than I have time available to be totally happy. It does not seem
>> to be handling the 'lowering' of 'odd bit-sized' symbols created in
>> the previous patch (to answer my own question), so I would have to
>> apply the patches (or fetch the above branch) to study some more.
> 
> Well, patch #16 doesn't contain the lowering, it kinda just enables
> the last bits to support (without out-of-bound access) packed structures
> including packed bitfields.
> 


What does the 'lowering' gain us? Or, in other words, what is still
missing after this series?

>> Hope you had a good holiday.
> 
> Thank you. In truth, it was strange and quiet, very quiet.
> 
> I wish you all the best for 2021!
> 
> -- Luc
>
Luc Van Oostenryck Jan. 5, 2021, 8:39 p.m. UTC | #5
On Tue, Jan 05, 2021 at 09:56:05AM -0800, Jacob Keller wrote:
> On 12/28/2020 1:33 PM, Luc Van Oostenryck wrote:
> > On Mon, Dec 28, 2020 at 05:18:50PM +0000, Ramsay Jones wrote:
> >>
> >> Patch #16 also looks good, but I would need to study it a bit more
> >> than I have time available to be totally happy. It does not seem
> >> to be handling the 'lowering' of 'odd bit-sized' symbols created in
> >> the previous patch (to answer my own question), so I would have to
> >> apply the patches (or fetch the above branch) to study some more.
> > 
> > Well, patch #16 doesn't contain the lowering, it kinda just enables
> > the last bits to support (without out-of-bound access) packed structures
> > including packed bitfields.
> > 
> 
> What does the 'lowering' gain us? Or, in other words, what is still
> missing after this series?

As a static checker, nothing is missing and the series is now mainlined.

The 'lowering' only matters if you want to somehow translate the
instructions used in the IR (Intermediate Representation) into
instructions for a more concrete machine, because now there are things
like: 'do a load of a 5-byte word'.

-- Luc
Jacob Keller Jan. 5, 2021, 10:07 p.m. UTC | #6
On 1/5/2021 12:39 PM, Luc Van Oostenryck wrote:
> On Tue, Jan 05, 2021 at 09:56:05AM -0800, Jacob Keller wrote:
>> On 12/28/2020 1:33 PM, Luc Van Oostenryck wrote:
>>> On Mon, Dec 28, 2020 at 05:18:50PM +0000, Ramsay Jones wrote:
>>>>
>>>> Patch #16 also looks good, but I would need to study it a bit more
>>>> than I have time available to be totally happy. It does not seem
>>>> to be handling the 'lowering' of 'odd bit-sized' symbols created in
>>>> the previous patch (to answer my own question), so I would have to
>>>> apply the patches (or fetch the above branch) to study some more.
>>>
>>> Well, patch #16 doesn't contain the lowering, it kinda just enables
>>> the last bits to support (without out-of-bound access) packed structures
>>> including packed bitfields.
>>>
>>
>> What does the 'lowering' gain us? Or, in other words, what is still
>> missing after this series?
> 
> As a static checker, nothing is missing and the series is now mainlined.
> 
> The 'lowering' only matters if you want to somehow translate the
> instructions used in the IR (Intermediate Representation) into
> instructions for a more concrete machine, because now there are things
> like: 'do a load of a 5-byte word'.
> 
> -- Luc
> 

Ok thanks, that makes sense.

- Jake