Re: compat code lacks support for __attribute__

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.06.2023 10:43, Olaf Hering wrote:
> I would like to share code between the hypervisor and xenalyze, so that
> every definition comes from a single place and is not duplicated in xen
> and xenalyze. This works as long as simple constructs like struct x {};
> are used. Depending on the data to be stored into the trace buffer, having
> support for __packed may reduce the amount of data that need to be copied.
> 
> The tooling currently converts ___attribute__ into compat___attribute__.
> Was support for __attribute__ intentionally left out, or was there just
> no usecase for it?

It was intentionally left out, as the public headers that are subject
to compat translation are supposed to not use any compiler extensions.
See also our checking that these headers build in plain ANSI C mode
(which of course doesn't catch all possible cases, as macros would
need actually using in order to spot issues).

However, if you're after adding packed attributes, and if you're
meaning to only communicate between Xen and the tool stack, then
the requirement above doesn't exist. Yet then I would also wonder
whether you need any compat translation in the first place. Those
packed structures would better be arch-/bitness-agnostic, wouldn't
they? So perhaps we could arrange for your additions to be excluded
from the compat translation machinery?

Another option to consider might be to use #pragma pack instead of
packed attributes. (I can't say off the top of my head whether such
#pragma-s would survive the translation.)

Jan