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?
