On 3/25/25 02:22, Philippe Mathieu-Daudé wrote:
On 24/3/25 21:49, Pierrick Bouvier wrote:
On 3/24/25 13:04, Richard Henderson wrote:
On 3/24/25 12:29, Pierrick Bouvier wrote:
On 3/24/25 10:39, Richard Henderson wrote:
On 3/24/25 03:21, Alex Bennée wrote:
+ #ifdef TARGET_BIG_ENDIAN
+ MemOp end = MO_BE;
+ #else
+ MemOp end = MO_LE;
+ #endif
+#endif
That's what MO_TE is for.
+/*
+ * Helpers copied from helpers.h just for handling target_ulong
values
+ * from gdbstub's GByteArray based on what the build config is. This
+ * will need fixing for single-binary.
+ */
+
+#if TARGET_LONG_BITS == 64
+#define ldtul_p(addr) ldq_p(addr)
+#define gdb_get_regl_value(m, b, v) gdb_get_reg64_value(m, b, v)
+#else
+#define ldtul_p(addr) ldl_p(addr)
+#define gdb_get_regl_value(m, b, v) gdb_get_reg32_value(m, b, v)
+#endif
Surely you're not intending to replicate this in any target that can
have multiple sizes?
This is not an improvement.
If I'm correct (and from v1), ppc is the only architecture having
registers defined with
target_long types.
With a quick check, mips, riscv, sparc do as well.
Right, I should have run the simple grep :)
So it's better to keep those macros defined in a separate header (out of
helpers.h, like helpers-target.h), so we can already start to cleanup
some targets, and do the rest of the work for the ones using
target_ulong type for later.
See also
https://lore.kernel.org/qemu-devel/[email protected]/
considering s/TARGET_LONG_SIZE/target_info_long_size()/
The problem is that both macros (ldtul, gdb_get_regl) have different
signatures. For gdb_get_regl, it could be solved by casting the pointer
to the right type.
However, for ldtul, it's much more dangerous, as ldl returns a signed
value, and ldq, an unsigned one. I'm not sure which signature we should
adopt for this.
That's why I proposed in the last series to replace ldtul_p with another
function returning value by pointer, so we can easily replace call sites
without the risk of truncating something.
