Calling napi_ functions from MinGW-compiled addon results in access violation #38782

Activity

1. Ayase-252

   added

   node-apiIssues and PRs related to Node-API.Issues and PRs related to Node-API.

   on May 23, 2021
2. sergio-eld commented on May 23, 2021

   

   sergio-eld

   on May 23, 2021

   Author

   More actions

   I've compared import address tables for both versions, and here is what I have found:
   MSVC-compiled hello.node

   Dump of file .\hello.node
   
   File Type: DLL
   
     Section contains the following imports:
   
       node.exe
                18000E1F8 Import Address Table
                18000E5E8 Import Name Table
                        0 time date stamp
                        0 Index of first forwarder reference
   
                           6707 napi_set_named_property
                           66A4 napi_create_function
                           66F3 napi_module_register
                           66AD napi_create_string_utf8
   

   MinGW-compiled hello.node

   There is an import table in .idata at 0xb32a9000
   
   The Import Tables (interpreted .idata section contents)
    vma:            Hint    Time      Forward  DLL       First
                    Table   Stamp     Chain    Name      Thunk
    00009000	00009084 00000000 00000000 000092c0 00009180
   
   	DLL Name: node.exe
   	vma:  Hint/Ord Member-Name Bound-To
   

   As can be seen the second one is empty...
   I guess it might actually be the reason. But I am still missing on the difference between linker and compiler flags
3. NickNaso commented on Jul 21, 2021

   

   NickNaso

   on Jul 21, 2021

   Member

   More actions

   Hi @ElDesalmado,
   in the past I had similar problem and I'm working to make it easy to solve. The first step was to create a repository that contains the Node-API headers here: https://github.com/nodejs/node-api-headers with Node-API you don't need to download all the Node.js include files.

   addon.cc

   #include <assert.h>
   #include <node_api.h>
   
   static napi_value Method(napi_env env, napi_callback_info info) {
       napi_status status;
       napi_value world;
       status = napi_create_string_utf8(env, "world", 5, &world);
       assert(status == napi_ok);
       return world;
   }
   
   #define DECLARE_NAPI_METHOD(name, func)                                        \
     { name, 0, func, 0, 0, 0, napi_default, 0 }
   
   static napi_value Initialize(napi_env env, napi_value exports) {
       napi_status status;
       napi_property_descriptor desc = DECLARE_NAPI_METHOD("hello", Method);
       status = napi_define_properties(env, exports, 1, &desc);
       assert(status == napi_ok);
       return exports;
   }
   
   extern "C" {
        NAPI_EXTERN  napi_value napi_register_module_v1(napi_env env, napi_value exports) {
           return (napi_value) Initialize(env, exports);
       }
   }

   CMakeLists.txt

   cmake_minimum_required(VERSION 3.16)
   
   project(addon_mingw)
   
   set(CMAKE_CXX_STANDARD 17)
   set(CMAKE_NODE_API_LIB libnode_api.a)
   
   include_directories(${CMAKE_SOURCE_DIR}/include)
   
   set(SOURCE_FILES
           ${CMAKE_CURRENT_SOURCE_DIR}/addon.cc
           )
   
   add_library(${PROJECT_NAME} SHARED ${SOURCE_FILES})
   set_target_properties(${PROJECT_NAME} PROPERTIES PREFIX "" SUFFIX ".node")
   target_link_libraries(${PROJECT_NAME} ${CMAKE_SOURCE_DIR}/lib/${CMAKE_NODE_API_LIB})
   
   # Define NAPI_VERSION
   add_definitions(-DNAPI_VERSION=3)

   In my CMakeLists.txt file you can see a library called libnode_api.a that I created from the list of symbols exported by Node-API. This is possible thanks to node-api-headers that is also a module (not yet published on npm) that you can install directly from git npm i https://github.com/nodejs/node-api-headers .
   Then you can use node-api-headers to build the node-api lib for example using a script like this:

   'use strict'
   
   const { promisify } = require('util');
   const exec = promisify(require('child_process').exec);
   const { symbols } = require('node-api-headers')
   const { writeFile } = require('fs').promises
   
   async function main() {
       const node_api_symbols = symbols.v8.node_api_symbols
       let node_api_lib = 'LIBRARY node.exe\n'
       node_api_lib += 'EXPORTS\n'
       node_api_lib += node_api_symbols.join('\n')
       await writeFile('./node_api.def', node_api_lib)
       await exec(' dlltool -d ./node_api.def -y libnode_api.a')
   }
   main().catch(err => console.error(err))

   The dlltool is part of MinGW.
   I hope that this info could help you.

   👍React with 👍2Reacted by Sergei Kolesnik and Nik
4. sergio-eld commented on Jul 22, 2021

   

   sergio-eld

   on Jul 22, 2021

   Author

   More actions

   @NickNaso The problem is caused by a bug within the MinGW linker in binutils. It corrupts the import table for some reason when there are a lot of mangled C++ symbols in an export lib provided by MSVC. It results in an empty import table.
   So, what you did is a solid workaround - you regenerate the export lib with only C API (n_api) functions. I admire your effort and certainly your solution is helpful.
   However, given that you still use MinGW binutils, it is not necessary to mess with node-api headers etc. All you have to do is to get all the C API symbols exported from node.exe (you could use regex, for instance) and generate an export lib. Simple python script would suffice.
   However "however", there is a third approach. Since MinGW and Clang on Windows can link directly to a binary, there might be no need for an export lib period. But this produces unresolved issues due to node.exe being basically an executable. Also, CMake on Windows does not support direct linking to a binary when using targets with target_link_libraries.

   To sum up: you did a good job.
5. mhdawson commented on Sep 3, 2021

   

   mhdawson

   on Sep 3, 2021

   Member

   More actions

   Looks like the question has been answered, closing. Please let us know if you think that was not the right thing to do.
6. mhdawson

   closed this as completedon Sep 3, 2021