Feature Request: Add tcg-interpreter (tci)

[BillBai]

Is there any chance we could add the tci interpreter to unicorn to support interpreted running mode.

This will allow unicorn to run on platforms on which JIT (or allocating memory with EXEC at runtime) is not allowed, such as un-jailbreaked iOS devices.

Also, the UTM project uses a threaded interpreter tcg backend to achieve better performance, which could also be an option for us.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[clauverjat]

Hello,

It looks like the stale label has been removed recently, is there any active work on this feature ?

[keroushe]

Hello,

any plans?

[61bcdefg]

I tried adding TCTI to unicorn and successfully passed the test-arm64, but I wasn't sure if there was some problems since it only took me one afternoon

[wtdcode]

Thanks for your work and it’s a good step indeed. You will need to make your features work with our other components and make at least CI work. It would be better if you write unit tests and samples.

---

From: abcdefg @.> Sent: Monday, February 5, 2024 5:09:17 PM To: unicorn-engine/unicorn @.> Cc: Subscribed @.***> Subject: Re: [unicorn-engine/unicorn] Feature Request: Add tcg-interpreter (tci) (Issue #1695)

I tried adding TCTI to unicornhttps://github.com/61bcdefg/unicorn-tcti and successfully passed the test-arm64, but I wasn't sure if there was some problems since it only took me one afternoon

― Reply to this email directly, view it on GitHubhttps://github.com/unicorn-engine/unicorn/issues/1695#issuecomment-1926519512, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHJULO7TCBSQMQE5USY44BLYSCOT3AVCNFSM57W7KT42U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJSGY2TCOJVGEZA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Naville]

Thanks for your work and it’s a good step indeed. You will need to make your features work with our other components and make at least CI work. It would be better if you write unit tests and samples.

Out of curiosity, why the non-target-dependent version of tci, which is available in qemu upstream , is removed in unicorn?

[wtdcode]

Thanks for your work and it’s a good step indeed. You will need to make your features work with our other components and make at least CI work. It would be better if you write unit tests and samples.

Out of curiosity, why the non-target-dependent version of tci, which is available in qemu upstream , is removed in unicorn?

Porting new host architecture is not as easy as it seems.

[Naville]

Thanks for your work and it’s a good step indeed. You will need to make your features work with our other components and make at least CI work. It would be better if you write unit tests and samples.

Out of curiosity, why the non-target-dependent version of tci, which is available in qemu upstream , is removed in unicorn?

Porting new host architecture is not as easy as it seems.

My understanding of qemu (which is ~0 when compared to you), is that tci is designed to be a universal tcg-IR interpreter?

I don't understand why that requires porting, though I only need instruction-level / mem access emulation and nothing else which probably why I'm ignorant

[wtdcode]

Thanks for your work and it’s a good step indeed. You will need to make your features work with our other components and make at least CI work. It would be better if you write unit tests and samples.

Out of curiosity, why the non-target-dependent version of tci, which is available in qemu upstream , is removed in unicorn?

Porting new host architecture is not as easy as it seems.

My understanding of qemu (which is ~0 when compared to you), is that tci is designed to be a universal tcg-IR interpreter?

I don't understand why that requires porting, though I only need instruction-level / mem access emulation and nothing else which probably why I'm ignorant

Porting to Unicorn means we need to support the mechanism of various functionalities provided by Unicorn like hooks, start/stop anywhere etc. Each requires efforts to modify either frontend or backend of tcg, which applies to any target/host. For instance, QEMU by itself is never designed to be able to stop at any address and thus Unicorn actually silently inserts exceptions at the exit point to allow users to stop emulation at any time (and ignore the spurious exceptions of course).

Strictly speaking, porting a new host is slightly easier than porting a target but the efforts are pretty similar. Porting a new host (backend) should be much easier actually, the sample above only applied to target (frontend)

[Naville]

Thanks. Is there any suggestion to someone who is interested in porting tci but lacks understanding of qemu/uc internals?

[wtdcode]

Generally, the port above by 61bcdefg seems a good start. The rough process is:

• Add constants, UC_MODE/ARCH/REG etc (maybe not applicable since it's a new host).
• Twink the qemu code to let it compile and work with Unicorn. This is the most tricky part. For example, qemu largely (ab)uses global variables while unicorn is a library with each instance having its own states. Many previous port attempts get stuck here due to many manual efforts.
• Fix unicorn functionalities. This part is a bit easier since Unicorn does much less hacks to host backends and the only caveat is read/write hooks. But still, be cautious about corner cases.
• Add tests/samples, fix cmake, update docs etc. These are minor but important to let others use your code.
• Potentially keep maintaining your backend =).

If you (or anyone) are interested, I'm happy to provide higher-level suggestions because my time has been limited recently, and I need to fix a few more urgent issues for the next release. My contacts are available in my GitHub profile.