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 <peter.mayd...@linaro.org>
wrote:

> On Wed, 20 Jul 2022 at 17:39, Kenneth Adam Miller
> <kennethadammil...@gmail.com> 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
>

Reply via email to