Re: [RFC PATCH-for-10.1 11/39] hw/arm: Use full "target/arm/cpu.h" path to include target's "cpu.h"

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 4/5/25 07:27, Philippe Mathieu-Daudé wrote:
> On 5/4/25 03:03, Pierrick Bouvier wrote:
>> On 4/4/25 14:53, Philippe Mathieu-Daudé wrote:
>>> On 4/4/25 20:20, Pierrick Bouvier wrote:
>>>> On 4/3/25 16:57, Philippe Mathieu-Daudé wrote:
>>>>> We would like to get rid of '-I target/$ARCH/' in the CPPFLAGS.
>>>>
>>>> While this change is correct, this is not strictly needed.
>>>> With the current approach, using a set of common files per architecture,
>>>> we can rely on this include to be present, and it does not block from
>>>> having common files.
>>>
>>> Indeed, I rebased this commit from my heterogeneous branch.
>>>
>>> I'll keeping carrying / rebasing it for various months, trying to
>>> remember to not keeping posting it.
>>>
>>> Or alternatively I'll post it in a separate "cleanup series", not
>>> mentioning single-binary or heterogeneous emulation.
>>>
>>
>> My point was not "please post that later", but simply to say those
>> changes are not needed, now or in the future.
>> We can have a specific include path for various files without
>> compromising the single binary/heterogenenous, as long as we compile it
>> only once.
> 
> Incorrect, this is required for heterogenenous emulation.
> 

There are probably two different topics here.

If by "this", you mean the current change (include explicit 
target/X/cpu.h), then no, it's not required.
Changing include "cpu.h" to include "target/arm/cpu.h" has absolutely no 
effect for the common files in hw/arm, as they are already compiled with 
-I target/arm. It produces the exact same compilation unit.
I did the same change as you do here when working on hw/arm, and finally 
understood it had no effect, so I reverted it, and simply let the 
original include "cpu.h".

If you were talking about accessing arm/cpu.h features, then I still 
don't see why it's needed. There is no reason any code out of hw/arm or 
target/arm should access this. If I missed something, feel free to post 
a concrete example of where it's needed.

In any case, if any hw code relies on cpu.h inclusion, it will not 
compile when we make it common, because cpu.h won't be found.
At this time, and only at this time, then we'll extract the expected 
interface, and expose it to common code. But before we meet the 
situation, I don't think we should do any of those changes.

Pierrick