Re: [PATCH 2/4] gendwarfksyms: Add a kABI rule to override byte_size attributes
From: Petr Pavlu
Date: Mon May 05 2025 - 07:58:03 EST
On 4/30/25 23:40, Sami Tolvanen wrote:
> A data structure can be partially opaque to modules if its
> allocation is handled by the core kernel, and modules only need
> to access some of its members. In this situation, it's possible
> to append new members to the structure without breaking the ABI,
> as long as the layout for the original members remains unchanged.
> For example, consider the following struct:
>
> struct s {
> unsigned long a;
> void *p;
> };
>
> gendwarfksyms --stable --dump-dies produces the following type
> expansion:
>
> variable structure_type s {
> member base_type long unsigned int byte_size(8) encoding(7) a
> data_member_location(0) ,
> member pointer_type {
> base_type void
> } byte_size(8) p data_member_location(8)
> } byte_size(16)
>
> To append new members, we can use the KABI_IGNORE() macro to
> hide them from gendwarfksyms --stable:
>
> struct s {
> /* old members with unchanged layout */
> unsigned long a;
> void *p;
>
> /* new members not accessed by modules */
> KABI_IGNORE(0, unsigned long n);
> };
>
> However, we can't hide the fact that adding new members changes
> the struct size, as seen in the updated type string:
>
> variable structure_type s {
> member base_type long unsigned int byte_size(8) encoding(7) a
> data_member_location(0) ,
> member pointer_type {
> base_type void
> } byte_size(8) p data_member_location(8)
> } byte_size(24)
>
> In order to support this use case, add a kABI rule that makes it
> possible to override the byte_size attribute for types:
>
> /*
> * struct s allocation is handled by the kernel, so
> * appending new members without changing the original
> * layout won't break the ABI.
> */
> KABI_BYTE_SIZE(s, 16);
>
> This results in a type string that's unchanged from the original
> and therefore, won't change versions for symbols that reference
> the changed structure.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx>
Reviewed-by: Petr Pavlu <petr.pavlu@xxxxxxxx>
-- Petr