Use of -on_load() module directive results in undecoded opcode abort

[rtATvw]

Using the -on_load() module directive produces varying undecoded opcode aborts upon module load.

[bettio]

on_load() is not yet supported. Anyway do you mind sharing any information what you would like to do?

[rtATvw]

I'm trying to adapt msantos/procket and travelping/gen_socket with the code below. If I understand correctly, compiled NIFs are linked into the AtomVM executable and beyond the generic enif_make_resource more specific APIs in the enifmake* series are unimplemented. Other than avm port drivers on the generic_unix platform dynamic loading of ELF objects doesn't seem to be implemented. When using the rebar3 atomvm plugin nifs are linked against the OTP BEAM's libraries and resultant shared objects are packed into avm files. Modifying NIFs or port drivers meant for OTP BEAM with AtomVM isn't trivial.

I think I'll need a different approach if I'm to use the driver with AtomVM. Adapting the socket/network driver and gen_udp/tcp for unix and netlink sockets into new port drivers and gen_servers may be more straightforward than what I'm trying to do.

Ultimately I'm trying to write a lightweight monitoring agent that runs on a platform that has little in the way of extra system memory where the OTP BEAM VM may be too resource intensive.

-on_load(on_load/0).

on_load() ->
  case erlang:function_exported(atomvm, module_info, 0) of
    false ->
      erlang:load_nif(progname(), []);
    true ->
      ok
  end.

[fadushin]

Probably aside from the generic unix port, none of the micro-platforms we have ported to support dlopen/dlsym -- pretty much any extension code needs to be built into the VM at link time. It's an unfortunate aspect of the target platforms.

There is some prototype dynamic loading code in the generic unix port, but it is by no means tested or documented. And our Nif support is nowhere near compliant with OTP.

Sorry about that. It could be the focus of future work, but not likely in the short term.

Also, just for the record, the rebar3 plugin only assembles BEAM files -- any compiled Nif or port driver code has to be linked into the VM at build time.

[rtATvw]

Not a problem. I understand that AtomVM is a work in progress.

Re: Rebar3 plugin Not quite what I meant. See the .so, .escript, .emtpy and .pem files in the listing below. Is the behaviour of the rebar3 plugin to include everything in the priv directory regardless of file type?

PackBEAM -l _build/default/lib/test_avm.avm
test_avm.beam *
...
certifi/priv/application.bin 
certifi/priv/cacerts.pem 
...
init.beam *
ledc_pwm.beam *
...
netlink.beam *
netlink_cache.beam *
...
gen_netlink/priv/application.bin 
gen_netlink/priv/decode_gen.escript 
...
gen_socket/priv/.empty 
gen_socket/priv/lib/gen_socket.so 
gen_socket/priv/lib/gen_socket_nif.so 
...
procket/priv/application.bin 
procket/priv/procket 
procket/priv/procket.so 

[fadushin]

Yes, pretty much. There is no filtering of data from priv