On 27.11.2023 18:57, Nicola Vetrini wrote:
> On 2023-11-27 15:59, Jan Beulich wrote:
>> On 27.11.2023 15:32, Nicola Vetrini wrote:
>>> - compat_set_{px,cx}_pminfo in x86/x86_64/cpufreq.c are perhaps
>>> declared
>>> with an autogenerated header?
>>
>> I don't think so. Only top-level hypercall handlers would be. This
>> works by
>> (perhaps even unintentional) trickery: xen/pmstat.h is included only
>> after
>> set_{c,p}x_pminfo are re-defined to compat_set_{c,p}x_pminfo, so the
>> same
>> declarations happen to serve two purposes (but of course don't provide
>> the
>> intended caller/callee agreement).
>>
>
> I didn't understand your explanation fully; I see xen/pmstat.h in
> cpufreq.c included before
> compat/platform.h which, as I understand it, redefines set_{c,p}x_pminfo
> to compat_set_{c,p}x_pminfo, therefore down below no declaration for
> compat_set_{c,p}x_pminfo is visible, triggering the violation.
May I suggest that you do what I also did in order to answer your original
question (and which imo you could have done up front): Generate the
preprocessed file(s) and check where the declaration(s) are? After all I
assume you understand that the compiler would choke if indeed there was no
declaration before use. The issue here is that there is a declaration
before use, but there is no (suitable) declaration before the definition.
Hence figuring out where the declaration is and why it won't be possible
to also use it for the definition (simply because there's nothing you can
include to achieve that effect) is the first step.
The (as said imo unintended) trickery can actually also be broken, by
simply adding an explicit inclusion of xen/pmstat.h to
x86_64/platform_hypercall.c near the top of the file. And it looks to me
as if adding this #include there is going to want to be part of the
eventual change (to deliberately make said trickery not work anymore).
Jan
