I need to determine the set of instruction encodings that the TCG can support for a given platform. I am not bothered whether the target runs at all, and in fact it is better if it doesn't, so runtime or translate time doesn't bother me. Imagine I were adding support for more instructions for a given platform. I would like to check that I'm using the API right. It's amazing that it's been so far and there's no way to check that the correct behavior occurs when a given encoding is encountered regarding the TCG. A boolean result from a can_translate called just when the target encounters the instruction would be good. Additionally, the ability to force the translation of arbitrary encodings would be good. I would like to not have to engineer some binary file format. On Wed, Jul 20, 2022 at 1:37 PM Peter Maydell wrote: > On Wed, 20 Jul 2022 at 17:39, Kenneth Adam Miller > wrote: > > That I know of, the TCG plugins do not allow me to feed the > > QEMU instance dynamically changing opcodes. I wouldn't use > > TranslatorOps if I don't have to. I want to facilitate a > > use case in which the contents of the target being emulated > > are changing, but it is not a self modifying target. I have > > to query and interact with the TCG to find out what opcodes > > are supported or not. > > I agree that feeding opcodes into the translator isn't what > TCG plugins are intended for. > > I'm definitely not clear on what you're trying to do here, > so it's hard to suggest some other approach, but linux-user > code shouldn't be messing with the internals of the translator > by grabbing the TranslatorOps struct. Among other things, > linux-user code is runtime and TranslatorOps is for > translate-time. > > Sometimes code in linux-user needs to be a bit over-familiar > with the CPU state, but we try to keep that to a minimum. > Generally that involves code in target/foo/ providing some > set of interface functions that code in linux-user/foo/ > can work with, typically passing it the CPU state struct. > > thanks > -- PMM >