Re: [RFC bpf-next] bpf: avoid clang-specific push/pop attribute pragmas in bpftool

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2024-05-03 at 15:14 -0700, Andrii Nakryiko wrote:
[...]

> With the decomposition into sort + emit string representation, it's
> now trivial to use in this flexible way.
> 
> Thoughts?

Compared to callbacks for attributes this adds the following:
- ability to filter-out some types;
- ability to add some pre-processor statements between specific types.

Compared to callbacks for attributes this lacks the following:
- ability to specify attributes for nested anonymous types
  (not important for preserve_access_index).

As I ranted in the off-list discussion, full flexibility is achievable
only with some kind of C AST:
- an API to produce such an AST;
- an API to modify AST where necessary;
- an API to serialize the AST as C code.

Adding such AST to libbpf is completely out of scope.

So, what we are left with is a set of half-measures:
1. a fixed attribute string as in Jose's patch;
2. a callback before printing attributes as suggested by me;
3. two API functions to get a sorted list of types and to print a type
   as suggested by Andrii.

And a set of use-cases:
a. capability to add some attribute for all structs;
b. capability to add some attribute for specific types;
c. capability to filter printed types.

(1) covers only (a);
(2) covers (a,b);
(3) covers (a,b,c).

Still, (3) has limited flexibility and I do not exclude the necessity
to add some sort of (2) in the future.

On the other hand, necessity to modify dump output arises not often,
so I think that (3) is preferable at the moment.