Re: [PATCH 01/16] exec/memory_ldst: extract memory_ldst declarations from cpu-all.h

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

On 3/10/25 08:17, Richard Henderson wrote:
> On 3/9/25 21:58, Pierrick Bouvier wrote:
>> They are now accessible through exec/memory.h instead, and we make sure
>> all variants are available for common or target dependent code.
> ...
>> diff --git a/include/exec/memory_ldst.h.inc b/include/exec/memory_ldst.h.inc
>> index 92ad74e9560..74519a88de0 100644
>> --- a/include/exec/memory_ldst.h.inc
>> +++ b/include/exec/memory_ldst.h.inc
>> @@ -19,7 +19,8 @@
>>     * License along with this library; if not, see <http://www.gnu.org/licenses/>.
>>     */
>>    
>> -#ifdef TARGET_ENDIANNESS
>> +uint8_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
>> +    hwaddr addr, MemTxAttrs attrs, MemTxResult *result);
>>    uint16_t glue(address_space_lduw, SUFFIX)(ARG1_DECL,
>>        hwaddr addr, MemTxAttrs attrs, MemTxResult *result);
> 
> You shouldn't be exposing
> 
>     address_space_lduw
> 
> to common code, only
> 
>     address_space_lduw_be
>     address_space_lduw_le
> 
> etc.  I'm not sure what you're trying to do here.
> 
> 
> r~

Taking another look at this, I don't see how we can avoid to expose 
those functions to common code.

The goal of those first two patches is to break the dependency to cpu.h, 
which can't be included from common code, and thus prevent any common 
code wanting to do memory op to access it.

All the calls to ld*_phys() and address_space_*() are indeed done from 
code related to a target (some of it in hw/). However, as we now move 
those compilation units to common, they still need to be accessed. The 
semantic stays exactly the same.

 From what I understand, non endian versions are simply passing 
DEVICE_NATIVE_ENDIAN as a parameter for address_space_ldl_internal, 
which will thus match the target endianness.

So what is the risk for common code to call this?