On 23/04/2025 11:09, Ben Dooks wrote:
In adding a new feature to the riscv target, it turns out the tb_flags
had already got to the 32-bit limit. Everyone other target has been
fine with uint32_t (except perhaps arm which does somethng strange to
extend tb_flags, I think).
To allow extending of tb_flags to be bigger, change the uint32_t to
a tb_flags_t which a target can define to be bigger (and do this for
riscv as having tb_flags_t be uint64_t somewhere is necessary to pick
out bugs in this translation).
This method of extension also stops having to go through each arch
fixing field usage and anything else that may arise, and given this
is currently only affecting the tcg, it can be done per target arch.
Note, target/riscv does not currently use any of the other flag bits
yet. The work is done as we would like to try the big-endian riscv
again and someone has already taken the last bit we where using at
(target/riscv/cpu.h#L666 adding PM_SIGNEXTEND where we had BE_DATA)
Q: Do the cpu_get_tb_state calls need uint32_t changing to the
tb_flag_t as part of this?
Q: As part of this, should we also define a FLAG_DP_TB or similar
wrapper for the relevant change?
Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
---
So after trying this, it looks like the struct TranslationBlock also
has a flags field in it and we missed updating that which had a follow
on issue of causing failures elsewhere.
Need to look into whether we should add a config and a global
tb_flags_t or if the TranslationBlock can include something that
defines tb_flags_t
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
