NativeBinder binds to _ex functions that don't exist

[xobs]

As of a403066de67f12c1e77e20a4b7e32463f65582db, NativeBinder appends _ex to every function it loads unless it is defined to not have exceptions. Unfortunately, as of 030048594e9e0734ab7d7ecbcd5918a15bb7247f these functions do not exist.

This results in a crash due to an access violation inside TranslationCPU::TranslationCPU() as it tries to invoke functions that do not exist. Namely, it first tries to call TlibSetTranslationCacheSize which gets mapped to tlib_set_translation_cache_size_ex, which does not exist.

The following patch may be applied to HEAD in order to fix this for now:

diff --git a/src/Emulator/Main/Utilities/Binding/NativeBinder.cs b/src/Emulator/Main/Utilities/Binding/NativeBinder.cs
index 3652fcae..6f07746e 100644
--- a/src/Emulator/Main/Utilities/Binding/NativeBinder.cs
+++ b/src/Emulator/Main/Utilities/Binding/NativeBinder.cs
@@ -352,10 +352,10 @@ private static string GetCName(string name, bool useExceptionWrapper)
             }).Select(x => x.Aggregate(string.Empty, (y, z) => y + char.ToLower(z))).
                 Aggregate((x, y) => x + "_" + y);

-            if(useExceptionWrapper)
-            {
-                cName += "_ex"; // Bind to exception wrapper instead of inner function
-            }
+            // if(useExceptionWrapper)
+            // {
+            //     cName += "_ex"; // Bind to exception wrapper instead of inner function
+            // }

             return cName;
         }

Are there may

[mateusz-holenko]

Hi @xobs, in 94083f21499b74de47df51038e1f2b08fd8b4f1 we introduced a mechanism for handling exceptions on the C#/C boundaries - those _ex functions are part of it. Although they are not explicitly visible in tlib, we use a special wrapper macro to automatically create them for us - take a look at: https://github.com/antmicro/tlib/blob/695c26046d89d54275a4e3bb1827a8da85ecbdfe/arch/arm/arch_exports.c#L101.

Is it possible that you are using an older tlib submodule (from before introducing this change) with the newer renode/renode-infrastructure repositories?

[xobs]

I don't think it's possible, unless it pulls files from somewhere outside of the source directory.

The steps I took were:

# Add Visual Studio 2022 to the path
$env:PATH += ";C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin"

# This should be the path to a "bin/" directory of the musl.cc toolchain,
# available for download from https://musl.cc/
$env:PATH += ";E:\Software\musl.cc\x86_64-w64-mingw32-native\bin\"

git clone [email protected]:renode/renode.git renode
cd .\renode\
git submodule update --init --recursive

# replace all instances of v4.5 with v4.8, e.g. by using sed or vscode
# ...

git -C lib clone https://github.com/renode/renode-resources.git resources
git -C lib/resources fetch
git -C lib/resources checkout origin/master

# Patch path to Xwt
(Get-Content .\lib\termsharp\TermSharp.csproj)|
    ForEach-Object {$_ -replace """xwt\\Xwt\\Xwt.csproj", """..\xwt\Xwt\Xwt.csproj"} |
    Set-Content .\lib\termsharp\TermSharp-working_copy.csproj

# Build CCTask, which is used to run subtasks
MSBuild /p:Configuration=Release /p:Platform="Any CPU" .\lib\cctask\CCTask.sln

# Copy the properties file, which contains various build environment settings
if (-not (Test-path output\properties.csproj)) {
    if (-not (Test-path output)) {
        New-Item -Type Directory output
    }
    Copy-Item src\Infrastructure\src\Emulator\Cores\windows-properties.csproj output\properties.csproj
}

MSBuild /p:Configuration=ReleaseWindows Renode.sln

I can verify that the version of GCC in the PATH is 9.3.1. I've also tried building with GCC 11.2.1 (which actually fails entirely with a no include path in which to search for limits.h error, so I think 11.2.1 is completely broken), GCC 10.2.1 gives errors about "relocation truncated to fit":

Link:
  LD: translate-arm-m-le.so
E:\Code\Renode\renode\src\Infrastructure\src\Emulator\Cores\translate.cproj(130,7): warning : obj/Release/obj-arm-m-32_le/
tlib\callbacks.o:callbacks.c:(.text+0x11f): relocation truncated to fit: R_X86_64_32S against symbol `unwind_state@tpoff'
defined in .data section in obj/Release/obj-arm-m-32_le/tlib\exports.o
E:\Code\Renode\renode\src\Infrastructure\src\Emulator\Cores\translate.cproj(130,7): warning : obj/Release/obj-arm-m-32_le/
tlib\callbacks.o:callbacks.c:(.text+0x135): relocation truncated to fit: R_X86_64_32S against symbol `unwind_state@tpoff'
defined in .data section in obj/Release/obj-arm-m-32_le/tlib\exports.o
...

I can get a build using x86_64-w64-mingw32-gcc.exe (GCC) 9.3.1 20200828 that works, but only if I comment out the line mentioned in the bug report. I can verify that there is no stale tlib anywhere because I have just done a fresh clone.

[mateusz-holenko]

We checked this and it seems to be related to the toolchain itself.

Following your instructions, but using Visual Studio 2019 build tools, without replacing v4.5 to v4.8 we were able to produce a working Renode with the toolchain specified in the documentation: MinGW x86_64-8.1.0-win32-sjlj-rt_v6-rev0.