Any chance for x86?

[EugeneSunrise]

Hello Dear, how many changes do I need make to add x86 .net6/7 support?

[Hitmasu]

Hello,

Probably if you add an x86 trampoline on this method should be enough:

Jitex/src/Jitex/Utils/MemoryHelper.cs

Lines 27 to 62 in 2258f2c

	private static (byte[] Code, int StartIndex) GetTrampoline()
	{
	byte[] trampoline;
	int startIndex;
	if (OSHelper.IsArm64)
	{
	trampoline = new byte[]
	{
	//ldr x16, .8
	0x50, 0x00, 0x00, 0x58,
	//br x16
	0x00, 0x02, 0x1F, 0xD6,
	//x64 address
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
	};
	startIndex = 8;
	}
	else
	{
	trampoline = new byte[]
	{
	// mov rax, 0000000000000000h ;Pointer to delegate
	0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	// jmp rax
	0xFF, 0xE0
	};
	startIndex = 2;
	}
	return (trampoline, startIndex);
	}

The startIndex represents the index in the array where the address should be written.

It might be necessary to adjust some lines to write a pointer (or 32 bits) into the array:

Jitex/src/Jitex/Utils/MemoryHelper.cs

Line 22 in 2258f2c

var address = BitConverter.GetBytes(methodAddress.ToInt64());

Jitex/src/Jitex/Utils/MemoryHelper.cs

Line 137 in 2258f2c

fs.Seek(address.ToInt64(), SeekOrigin.Begin);

If it doesn't work, please let me know, and I can assist with the implementation.

[EugeneSunrise]

Tested on windows.

I've changed GetTrampoline(IntPtr methodAddress) method:
from var address = BitConverter.GetBytes(methodAddress.ToInt64());
to var address = BitConverter.GetBytes(methodAddress.ToInt32());

Then byte[] Code, int StartIndex) GetTrampoline():
from trampoline = new byte[] { 0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0 }; startIndex = 2;
to trampoline = new byte[] { 0xB8, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0 }; startIndex = 1;

And currently stuck in ManagedJit.CompileMethod(IntPtr thisPtr, IntPtr comp, IntPtr info, uint flags, IntPtr nativeEntry, out int nativeSizeOfCode)

Line MethodInfo methodInfo = new MethodInfo(info);
info(Pointer to CORINFO_METHOD_INFO) always -1

Any ideas?

[Hitmasu]

I'll investigate that.

Which version of .NET are you currently testing?

[EugeneSunrise]

I'll i

.net 7 x86

[RedDot-3ND7355]

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64)
If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.

Description: The process was terminated due to an unhandled exception.
Stack:
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
   at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)
   at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Delegate.DynamicInvokeImpl(System.Object[])
   at System.Delegate.DynamicInvoke(System.Object[])
   at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])
   at Jitex.JIT.ManagedJit.PrepareHook()
   at Jitex.JIT.ManagedJit..ctor()
   at Jitex.JIT.ManagedJit.GetInstance()
   at Jitex.JitexManager.get_Jit()
   at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)
   at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)
   at JitTest.InitializeJit.MyMethodResolver()
   at JitTest.InitializeJit.JitInit()

Followed By...

Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef
Exception code: 0xc0000005

[Hitmasu]

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64) If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.

Description: The process was terminated due to an unhandled exception.
Stack:
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
   at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)
   at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Delegate.DynamicInvokeImpl(System.Object[])
   at System.Delegate.DynamicInvoke(System.Object[])
   at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])
   at Jitex.JIT.ManagedJit.PrepareHook()
   at Jitex.JIT.ManagedJit..ctor()
   at Jitex.JIT.ManagedJit.GetInstance()
   at Jitex.JitexManager.get_Jit()
   at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)
   at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)
   at JitTest.InitializeJit.MyMethodResolver()
   at JitTest.InitializeJit.JitInit()

Followed By...

Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef
Exception code: 0xc0000005

This occurs because Jitex attempts to insert an x64 trampoline on x86. You can resolve this error by adding an x86 trampoline. However, another error will arise, as Eugene mentioned, due to the fact that on x86, the sizes of certain internal structs in .NET changes.

Probably, by the end of this month, I can release a version with x86 support.

[EugeneSunrise]

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64) If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.

Description: The process was terminated due to an unhandled exception.

Stack:

at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)

at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)

at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)

at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)

at System.Delegate.DynamicInvokeImpl(System.Object[])

at System.Delegate.DynamicInvoke(System.Object[])

at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])

at Jitex.JIT.ManagedJit.PrepareHook()

at Jitex.JIT.ManagedJit..ctor()

at Jitex.JIT.ManagedJit.GetInstance()

at Jitex.JitexManager.get_Jit()

at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)

at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)

at JitTest.InitializeJit.MyMethodResolver()

at JitTest.InitializeJit.JitInit()

Followed By...

Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef

Exception code: 0xc0000005

This occurs because Jitex attempts to insert an x64 trampoline on x86. You can resolve this error by adding an x86 trampoline. However, another error will arise, as Eugene mentioned, due to the fact that on x86, the sizes of certain internal structs in .NET changes.

Probably, by the end of this month, I can release a version with x86 support.

Thank you for your support🙏🏼❤️

[EugeneSunrise]

🙏🏼

[Hitmasu]

Apologies for the delay.

I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

• Resolve Methods.
• Resolve Tokens.
• Intercept Methods.

However, the following features are not included in this preview:

• Some methods from MethodHelper.
• Resolve DynamicMethod.
• Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.

The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.

Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.

This preview version should suffice for most scenarios. If not work for you, let me know.

[EugeneSunrise]

Apologies for the delay.

I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

• Resolve Methods.
• Resolve Tokens.
• Intercept Methods.

However, the following features are not included in this preview:

• Some methods from MethodHelper.
• Resolve DynamicMethod.
• Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.

The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.

Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.

This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

[Hitmasu]

Apologies for the delay.
I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

• Resolve Methods.
• Resolve Tokens.
• Intercept Methods.

However, the following features are not included in this preview:

• Some methods from MethodHelper.
• Resolve DynamicMethod.
• Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.
The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.
Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.
This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

Great!

I'm planning to incorporate support for .NET 8 and aim to release a stable, non-preview version soon.

It's going to be wonderful! Could you share your project so that I can include a reference to it in Jitex as well?

---

As this version doesn't offer complete x86 support, I'll keep this issue open with the #help tag.

[EugeneSunrise]

Apologies for the delay.
I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

• Resolve Methods.
• Resolve Tokens.
• Intercept Methods.

However, the following features are not included in this preview:

• Some methods from MethodHelper.
• Resolve DynamicMethod.
• Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.
The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.
Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.
This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

Great!

I'm planning to incorporate support for .NET 8 and aim to release a stable, non-preview version soon.

It's going to be wonderful! Could you share your project so that I can include a reference to it in Jitex as well?

As this version doesn't offer complete x86 support, I'll keep this issue open with the #help tag.

We gave you credits in this repo and this. Actually I don't really know how you feel about these "stuff", but in our case we needed to change code in runtime and jitex handled it 200% well. Let me know if you're not comfortable with these "stuff", we'll clean up our repositories, but I think this is not bad example of using jitex to its full potential😈

[Hitmasu]

We gave you credits in this repo and this. Actually I don't really know how you feel about these "stuff", but in our case we needed to change code in runtime and jitex handled it 200% well. Let me know if you're not comfortable with these "stuff", we'll clean up our repositories, but I think this is not bad example of using jitex to its full potential😈

Thank you for credits!

I don't see any issues in utilizing Jitex for this purpose. Jitex is open-source under the MIT license, and since I'm not responsible for those projects, i don't see any problems.

However, referencing that project in Jitex might pose some laws problems for me. Due to this risk, I'd rather refrain from including references to both projects in the readme.

I hope you understand the cautious approach.