[Bug target/120241] New: bpf: problem with preserve_access_index in "nested" struct types

[jemarch at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120241

            Bug ID: 120241
           Summary: bpf: problem with preserve_access_index in "nested"
                    struct types
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jemarch at gcc dot gnu.org
  Target Milestone: ---

The preserve_access_index C attribute marks particular struct types so CO-RE
relocations get emitted for each access (be it load or store) of a field of
values of such types. In C struct types can appear to be nested, like in:

struct foo
{
   struct bar
   {
     ...
   } f;

   ...
}

However, the C language doesn't actually have the notion of nested struct
types.  They appear nested in the program source, but they are no different
semantically in any way than having them defined as:


struct bar
{
  ...
};

struct foo
{
   struct bar f;
}

So if the preserve_access_index attribute gets applied to struct foo:

struct foo __attribute__((preserve_access_index))
{
   struct bar
   {
      ...
   } f;
   ...
}

One would expect for that to be equivalent to:

struct bar
{
  int g;
  ...
};

struct foo __attribute__((preserve_access_index))
{
  struct bar f;
  ...
}

And therefore the attribute wouldn't apply when accessing a field in struct
bar, like foo.f.g.  That would generate one CO-RE reloc for the access of the
field f, but no CO-RE reloc for the access of field g.

However, the kernel BPF side wants the attribute to also apply to the access of
g in this case if struct bar is defined "nested" to struct foo.  clang
implements it this way.