Comments (8)
@iKlask The symbol name of windows 32 may start with '_', so "_aot_stack_sizes" should be same as "aot_stack_sizes" in windows/linux 64, since the relocation for the latter is redirected into the relocation for the name of ".aot_stack_sizes" (the section name), I doubt we should redirect "_aot_stack_sizes" also. Could you please try the patch below:
diff --git a/core/iwasm/compilation/aot_emit_aot_file.c b/core/iwasm/compilation/aot_emit_aot_file.c
index 758681d6..3bad41f3 100644
--- a/core/iwasm/compilation/aot_emit_aot_file.c
+++ b/core/iwasm/compilation/aot_emit_aot_file.c
@@ -3947,7 +3947,12 @@ aot_resolve_object_relocation_group(AOTObjectData *obj_data,
* Note: aot_stack_sizes_section_name section only contains
* stack_sizes table.
*/
- if (!strcmp(relocation->symbol_name, aot_stack_sizes_name)) {
+ if (!strcmp(relocation->symbol_name, aot_stack_sizes_name)
+ /* in windows 32, the symbol name may start with '_' */
+ || (strlen(relocation->symbol_name) > 0
+ && relocation->symbol_name[0] == '_'
+ && !strcmp(relocation->symbol_name + 1,
+ aot_stack_sizes_name))) {
/* discard const */
relocation->symbol_name = (char *)aot_stack_sizes_section_name;
}
from wasm-micro-runtime.
since the relocation for the latter is redirected into the relocation for the name of ".aot_stack_sizes" (the section name), I doubt we should redirect "_aot_stack_sizes" also.
Sorry I'm a little confused on that. So "_aot_stack_sizes" is not related to ".aot_stack_sizes" or is it? I understand how win32 can add '_' to symbols, so should this be the same as the ".aot_stack_sizes" section? I noticed that during load relocations (in do_text_relocation()
) there is a check to see if the symbol name is the same as the macro AOT_STACK_SIZES_SECTION_NAME which is defined in aot.h as:
#define AOT_STACK_SIZES_SECTION_NAME ".aot_stack_sizes"
it fails that check and eventually moves onto resolve_target_sym()
which fails to find this as a symbol in the target_symbol_map (does not exist). Should it be passing that check or is something else the problem?
this is the cmake config file I use for building my iwasm.exe, could I be missing something or doing something wrong?
set (WAMR_BUILD_PLATFORM "windows")
set (WAMR_BUILD_TARGET X86_32)
set (WAMR_BUILD_INTERP 1)
set (WAMR_BUILD_FAST_INTERP 0)
set (WAMR_BUILD_AOT 1)
set (WAMR_BUILD_JIT 0)
set (WAMR_BUILD_FAST_JIT 0)
set (WAMR_BUILD_SIMD 1)
set (WAMR_BUILD_TAIL_CALL 1)
set (WAMR_CONFIGUABLE_BOUNDS_CHECKS 1)
set (CMAKE_C_STANDARD 11)
set (CMAKE_CXX_STANDARD 20)
from wasm-micro-runtime.
Yes, they are the same, "aot_stack_sizes" is the name of an internal global array and the array is put into a data section named ".aot_stack_sizes", and the aot code accesses the array elements, here is a sample LLVM IR file generated by wamrc --format=llvmir-unopt --target=i386 --target-abi=msvc -o test.ll <wasm_file>
:
; ModuleID = 'WASM Module'
source_filename = "WASM Module"
target datalayout = "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32-a:0:32-S32"
target triple = "i386-pc-windows-msvc"
@aot_stack_sizes = internal global [14 x i32] [i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1, i32 -1], section ".aot_stack_sizes"
@aot_stack_sizes_alias = alias [14 x i32], ptr @aot_stack_sizes
; Function Attrs: noinline
define i32 @"aot_func#0"(ptr %exec_env) #0 {
Note that the data section ".aot_stack_sizes" (but not "aot_stack_sizes" or "_aot_stack_sizes") will be created by aot loader, so the relocation to "aot_stack_sizes" or "_aot_stack_sizes" should be change to the relocation to that data section instead. Could you leave iwasm unchanged, apply the patch of aot_emit_aot_file.c, rebuild wamrc and generate the AOT file and test again?
from wasm-micro-runtime.
Ah I see now. Yes applying that patch for wamrc fixed the "aot_stack_sizes" issue, but now it moves onto the the other symbol which was added by --bounds-checks=1 and fails again. I assume there's something else that needs to be patched for the leading "_":
AOT module load failed: resolve symbol _aot_func_internal#0 failed
from wasm-micro-runtime.
Yes, please try:
diff --git a/core/iwasm/aot/aot_loader.c b/core/iwasm/aot/aot_loader.c
index 759954ad..3e832c27 100644
--- a/core/iwasm/aot/aot_loader.c
+++ b/core/iwasm/aot/aot_loader.c
@@ -2917,6 +2917,17 @@ do_text_relocation(AOTModule *module, AOTRelocationGroup *group,
}
symbol_addr = module->func_ptrs[func_index];
}
+ else if (!strncmp(symbol, "_" AOT_FUNC_INTERNAL_PREFIX,
+ strlen("_" AOT_FUNC_INTERNAL_PREFIX))) {
+ p = symbol + strlen("_" AOT_FUNC_INTERNAL_PREFIX);
+ if (*p == '\0'
+ || (func_index = (uint32)atoi(p)) > module->func_count) {
+ set_error_buf_v(error_buf, error_buf_size, "invalid symbol %s",
+ symbol);
+ goto check_symbol_fail;
+ }
+ symbol_addr = module->func_ptrs[func_index];
+ }
#endif
else if (is_text_section(symbol)) {
symbol_addr = module->code;
from wasm-micro-runtime.
Please see #3231.
from wasm-micro-runtime.
Thank you.
EDIT: I realize now no need to compile wamrc for 32 bit in my case. the fixes in aot_loader are intended for the 32bit runtime. With the fixes in #3231 my wasm binary can be compiled to 32bit aot and execute on a 32bit runtime.
However I'm having issues building the x86 version of wamrc. I have been building and using an x64 version of wamrc to compile 32bit AOT code, however one of the fixes you linked is wrapped around a macro that expects defined(BUILD_TARGET_X86_32)
.
When I try regenerating the cmake project for the wamr compiler with "-DWAMR_BUILD_TARGET=x86_32"
, it enables the correct flags but does not setup the visual studio project configuration to Win32.
When forcing win32 in visual studio I end up with other errors since dependency static libraries like vmlib, aotclib, uvwasi_a, and uv_a are all generated and built for x64.
I'm not sure if theres something simple im missing or if I need to be forcing the WAMR_BUILD_TARGET
on every dependency somehow.
from wasm-micro-runtime.
Thank you.
EDIT: I realize now no need to compile wamrc for 32 bit in my case. the fixes in aot_loader are intended for the 32bit runtime. With the fixes in #3231 my wasm binary can be compiled to 32bit aot and execute on a 32bit runtime.
However I'm having issues building the x86 version of wamrc. I have been building and using an x64 version of wamrc to compile 32bit AOT code, however one of the fixes you linked is wrapped around a macro that expects
defined(BUILD_TARGET_X86_32)
.When I try regenerating the cmake project for the wamr compiler with
"-DWAMR_BUILD_TARGET=x86_32"
, it enables the correct flags but does not setup the visual studio project configuration to Win32.When forcing win32 in visual studio I end up with other errors since dependency static libraries like vmlib, aotclib, uvwasi_a, and uv_a are all generated and built for x64.
I'm not sure if theres something simple im missing or if I need to be forcing the
WAMR_BUILD_TARGET
on every dependency somehow.
OK, so let's merge #3231 first. For building 32-bit wamr compiler on Windows x86_64, we have no experience either, per my understanding, the llvm should be built as 32-bit first, and setting -DWAMR_BUILD_TARGET=x86_32
for wamrc-compiler cmake project may be not enough, maybe you should also setting some other cmake flags like CMAKE_SYSTEM_PROCESSOR?
from wasm-micro-runtime.
Related Issues (20)
- Empty `fd_pread` fails when it should succeed HOT 2
- wasm_is_reftype_supers_of_extern seems unused HOT 1
- Unexpected exception on fast interpreter mode HOT 2
- Unexpected behavior on fast interpreter mode HOT 2
- Wrong execution reuslt on fast interpreter mode HOT 2
- aot_load_const_from_table is inefficient
- "duplicate export name" check is O(n^2) HOT 3
- Compilation errors when build iwasm with GC and EH support
- iwasm: WASM module load failed: struct or array as field is not supported in constant expr HOT 6
- iwasm: WASM module load failed: type mismatch: expect (ref null ht) but got other1 unknown type HOT 5
- exception handler intercepts c++ exceptions in the host on windows HOT 2
- WASM module instantiate failed on Mac HOT 1
- aot: xtensa xip triggers llvm assertion failure
- BH_DEBUG not set in multi-configuration cmake (eg. visual studio)
- printf_wrapper (libc builtin) makes multiple calls to os_printf with individual characters HOT 6
- Can AOT file built on windows run directly on other platforms? HOT 5
- How to load and run another wasm in a running wasm? HOT 6
- Exception Handling Support in Fast Interpreter HOT 1
- iwasm with aot file fail with SIGSEGV HOT 4
- Exception for Assemblyscript HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasm-micro-runtime.