Enable AoT and wamr-sdk, and change arguments of call wasm API (#157)

* Implement memory profiler, optimize memory usage, modify code indent

* Implement memory.grow and limit heap space base offset to 1G; modify iwasm build type to Release and 64 bit by default

* Add a new extension library: connection

* Fix bug of reading magic number and version in big endian platform

* Re-org platform APIs: move most platform APIs from iwasm to shared-lib

* Enhance wasm loader to fix some security issues

* Fix issue about illegal load of EXC_RETURN into PC on stm32 board

* Updates that let a restricted version of the interpreter run in SGX

* Enable native/app address validation and conversion for wasm app

* Remove wasm_application_exectue_* APIs from wasm_export.h which makes confused

* Refine binary size and fix several minor issues

Optimize interpreter LOAD/STORE opcodes to decrease the binary size
Fix issues when using iwasm library: _bh_log undefined, bh_memory.h not found
Remove unused _stdin/_stdout/_stderr global variables resolve in libc wrapper
Add macros of global heap size, stack size, heap size for Zephyr main.c
Clear compile warning of wasm_application.c

* Add more strict security checks for libc wrapper API's

* Use one libc wrapper copy for sgx and other platforms; remove bh_printf macro for other platform header files

* Enhance security of libc strcpy/sprintf wrapper function

* Fix issue of call native for x86_64/arm/mips, add module inst parameter for native wrapper functions

* Remove get_module_inst() and fix issue of call native

* Refine wgl lib: remove module_inst parameter from widget functions; move function index check to runtime instantiate

* Refine interpreter call native process, refine memory boudary check

* Fix issues of invokeNative function of arm/mips/general version

* Add a switch to build simple sample without gui support

* Add BUILD_TARGET setting in makefile to replace cpu compiler flags in source code

* Re-org shared lib header files, remove unused info; fix compile issues of vxworks

* Add build target general

* Remove unused files

* Update license header

* test push

* Restore file

* Sync up with internal/feature

* Sync up with internal/feature

* Rename build_wamr_app to build_wasm_app

* Fix small issues of README

* Enhance malformed wasm file checking
Fix issue of print hex int and implement utf8 string check
Fix wasi file read/write right issue
Fix minor issue of build wasm app doc

* Sync up with internal/feature

* Sync up with internal/feature: fix interpreter arm issue, fix read leb issue

* Sync up with internal/feature

* Fix bug of config.h and rename wasi config.h to ssp_config.h

* Sync up with internal/feature

* Import wamr aot

* update document

* update document

* Update document, disable WASI in 32bit

* update document

* remove files

* update document

* Update document

* update document

* update document

* update samples

* Sync up with internal repo
This commit is contained in:
wenyongh
2020-01-21 13:26:14 +08:00
committed by Wang Xin
parent 2a4528c749
commit 46b93b9d22
464 changed files with 25137 additions and 7911 deletions

View File

@ -1,8 +1,16 @@
Introduction
==============
This project builds out both host tools running on the host side, and an application running on the device side. The device application consists of iwasm, application library, application manager, timers and sensors support. The device runs on Linux OS and interacts with host tools.
It demonstrates an end to end scenario, the wasm applications life cycle management and communication programming models.
"simple" sample introduction
==============
This sample demonstrates following scenarios:
- Use tool "host_tool" to remotely install/uninstall wasm applications from the WAMR runtime over either TCP socket or UART cable
- Inter-app communication programming models
- Communication between WASM applications and the remote app host_tool
- A number of WASM applications built on top of WAMR application framework API sets
Directory structure
------------------------------
@ -19,25 +27,20 @@ simple/
├── connection.c
├── event_publisher.c
├── event_subscriber.c
├── gui.c
├── request_handler.c
├── request_sender.c
├── sensor.c
└── timer.c
```
- build.sh<br/>
The script to build all binaries.
- build_no_gui.sh<br/>
The script to build all binaries without gui library support.
- CMakeLists.txt<br/>
CMake file used to build the simple application.
- README.md<br/>
The file you are reading currently.
- src/ext_lib_export.c<br/>
This file is used to export native APIs. See the `The mechanism of exporting Native API to WASM application` section in WAMR README.md for detail.
- src/iwam_main.c<br/>
This file is the implementation by platform integrator. It implements the interfaces that enable the application manager communicating with the host side. See `{WAMR_ROOT}/core/app-mgr/app-mgr-shared/app_manager_export.h` for the definition of the host interface.
## Set physical communication between device and remote
```
/* Interfaces of host communication */
typedef struct host_interface {
@ -45,69 +48,45 @@ typedef struct host_interface {
host_send_fun send;
host_destroy_fun destroy;
} host_interface;
```
The `host_init_func` is called when the application manager starts up. And `host_send_fun` is called by the application manager to send data to the host.
Define a global variable "interface" of the data structure:
```
host_interface interface = {
.init = host_init,
.send = host_send,
.destroy = host_destroy
};
```
This interface is passed to application manager by calling
This interface is passed to application manager during the runtime startup:
```
app_manager_startup(&interface);
```
The `host_init_func` is called when the application manager starts up. And `host_send_fun` is called by the application manager to send data to the host.
>**Note:** Currently application manager keeps running and never exit, `host_destroy_fun` has no chance to get executed. So you can leave this API implementation empty.
>
- src/main.c<br/>
The main file.
- wasm-apps<br/>
Source files of sample wasm applications.
**Note:** The connection between simple and host_tool is TCP by default. The simple application works as a server and the host_tool works as a client. You can also use UART connection. To achieve this you have to uncomment the below line in CMakeLists.txt and rebuild.
Configure 32 bit or 64 bit build
==============
On 64 bit operating system, there is an option to build 32 bit or 64 bit binaries. In file `CMakeLists.txt`, modify the line:
`set (BUILD_AS_64BIT_SUPPORT "YES")`
where `YES` means 64 bit build while `NO` means 32 bit build.
Install required SDK and libraries
==============
- 32 bit SDL(simple directmedia layer) (Note: only necessary when `BUILD_AS_64BIT_SUPPORT` is set to `NO`)
Use apt-get:
`sudo apt-get install libsdl2-dev:i386`
Or download source from www.libsdl.org:
```
./configure C_FLAGS=-m32 CXX_FLAGS=-m32 LD_FLAGS=-m32
make
sudo make install
```
- 64 bit SDL(simple directmedia layer) (Note: only necessary when `BUILD_AS_64BIT_SUPPORT` is set to `YES`)
Use apt-get:
`sudo apt-get install libsdl2-dev`
Or download source from www.libsdl.org:
```
./configure
make
sudo make install
#add_definitions (-DCONNECTION_UART)`
```
- Install EMSDK
```
https://emscripten.org/docs/tools_reference/emsdk.html
```
To run the UART based test, you have to set up a UART hardware connection between host_tool and the simple application. See the help of host_tool for how to specify UART device parameters.
Build all binaries
Build the sample
==============
Execute the build.sh script then all binaries including wasm application files would be generated in 'out' directory.
`./build.sh`
Or execute the build_no_gui.sh script to build all binaries without gui library support.
`./build_no_gui.sh`
Out directory structure
------------------------------
**Out directory structure**
```
out/
├── host_tool
@ -116,7 +95,6 @@ out/
├── connection.wasm
├── event_publisher.wasm
├── event_subscriber.wasm
├── gui.wasm
├── request_handler.wasm
├── request_sender.wasm
├── sensor.wasm
@ -130,42 +108,22 @@ out/
- simple:
A simple testing tool running on the host side that interact with WAMR. It is used to install, uninstall and query WASM applications in WAMR, and send request or subscribe event, etc. See the usage of this application by executing "./simple -h".
`./simple -h`
>****Note:**** The connection between simple and host_tool is TCP by default and is what this guide uses. The simple application works as a server and the host_tool works as a client. You can also use UART connection. To achieve this you have to uncomment the below line in CMakeLists.txt and rebuild. You have to set up a UART hardware connection between 2 machines one of which runs the host_tool and the other runs the simple application. See the help of host_tool and the simple application to know how to specify UART device parameters.<br/>
`#add_definitions (-DCONNECTION_UART)`
>
- wasm-apps:
Sample wasm applications that demonstrate all APIs of the WAMR programming model. The source codes are in the wasm-apps directory under the root of this project.
+ connection.wasm<br/>
This application shows the connection programming model. It connects to a TCP server on 127.0.0.1:7777 and periodically sends message to it.
+ event_publisher.wasm<br/>
This application shows the sub/pub programming model. The pub application publishes the event "alert/overheat" by calling api_publish_event() API. The subscriber could be host_tool or other wasm application.
+ event_subscriber.wasm<br/>
This application shows the sub/pub programming model. The sub application subscribes the "alert/overheat" event by calling api_subscribe_event() API so that it is able to receive the event once generated and published by the pub application. To make the process clear to interpret, the sub application dumps the event when receiving it.
+ gui.wasm<br/>
This application shows the built-in 2D graphical user interface API with which various widgets could be created.
+ request_handler.wasm<br/>
This application shows the request/response programming model. The request handler application registers 2 resources(/url1 and /url2) by calling api_register_resource_handler() API. The request sender could be host_tool or other wasm application.
+ request_sender.wasm<br/>
This application shows the request/response programming model. The sender application sends 2 requests, one is "/app/request_handler/url1" and the other is "url1". The former is an accurate request which explicitly specifies the name of request handler application in the middle of the URL and the later is a general request.
+ sensor.wasm<br/>
This application shows the sensor programming model. It opens a test sensor and configures the sensor event generating interval to 1 second. To make the process clear to interpret, the application dumps the sensor event when receiving it.
+ timer.wasm<br/>
This application shows the timer programming model. It creates a periodic timer that prints the current expiry number in every second.
Run the scenario
Run the sample
==========================
- Enter the out directory<br/>
- Enter the out directory
```
$ cd ./out/
```
- Startup the 'simple' process works in TCP server mode and you would see "App Manager started." is printed.<br/>
- Startup the 'simple' process works in TCP server mode and you would see "App Manager started." is printed.
```
$ ./simple -s
App Manager started.
```
- Query all installed applications<br/>
- Query all installed applications
```
$ ./host_tool -q
@ -175,7 +133,7 @@ response status 69
}
```
The `69` stands for response status to this query request which means query success and a payload is attached with the response. See `{WAMR_ROOT}/core/iwasm/lib/app-libs/base/wasm_app.h` for the definitions of response codes. The payload is printed with JSON format where the `num` stands for application installations number and value `0` means currently no application is installed yet.
The `69` stands for response code SUCCESS. The payload is printed with JSON format where the `num` stands for application installations number and value `0` means currently no application is installed yet.
- Install the request handler wasm application<br/>
```
@ -183,20 +141,11 @@ $ ./host_tool -i request_handler -f ./wasm-apps/request_handler.wasm
response status 65
```
The `65` stands for response status to this installation request which means success.
Output of simple
```
Install WASM app success!
sent 16 bytes to host
WASM app 'request_handler' started
```
Now the request handler application is running and waiting for host or other wasm application to send a request.
- Query again<br/>
- Query again
```
$ ./host_tool -q
$ ./host_tool -q
response status 69
{
@ -207,7 +156,7 @@ response status 69
```
In the payload, we can see `num` is 1 which means 1 application is installed. `applet1`stands for the name of the 1st application. `heap1` stands for the heap size of the 1st application.
- Send request from host to specific wasm application<br/>
- Send request from host to specific wasm application
```
$ ./host_tool -r /app/request_handler/url1 -A GET
@ -220,7 +169,7 @@ response status 69
We can see a response with status `69` and a payload is received.
Output of simple
Output of simple application:
```
connection established!
Send request to applet: request_handler
@ -242,7 +191,7 @@ response status 69
}
```
Output of simple
Output of simple application:
```
connection established!
Send request to app request_handler success.
@ -252,7 +201,7 @@ sent 150 bytes to host
Wasm app process request success.
```
- Install the event publisher wasm application<br/>
- Install the event publisher wasm application
```
$ ./host_tool -i pub -f ./wasm-apps/event_publisher.wasm