Segment fault with arm-linux in iotjs

[seanshpark]

Please read jerryscript-project/iotjs#117 (comment) for details.
JerryScript standalone built for arm-linux running in RPi2 is ok.

[seanshpark]

Changing jmp_buf size from 14 to 16 solves this.

typedef uint64_t jmp_buf[14];

@ruben-ayrapetyan , can you guess why this could solve the problem? :)

[seanshpark]

#294

[ruben-ayrapetyan]

@seanshpark,
seems that jerry, built for iotjs, uses headers of jerry-libc, while actually it is linked to another libc.

The another libc has its own implementation of setjmp with another jmp_buf layout (probably, 256 bytes size, as specified in glibc's setjmp.h for arm-linux-gnueabihf).
When switching to 16 elements, size of jmp_buf changes to 128 bytes. May be, the size is not really enough for the another setjmp implementation, and the failure just becomes hidden, until some little change in memory layout.

To solve the issue, correct include path of an actually used libc's should be set.

What do you think of the following options?

• pass EXTERNAL_LIBC_INTERFACE options from tools/build.py of iotjs to jerry with correct include path;
• introduce another jerry's build option, like USE_DEFAULT_LIBC, for switching jerry to include path of default libc, provided by compiler.

[seanshpark]

@ruben-ayrapetyan , thank you very much for the analysis.
USE_DEFAULT_LIBC will be nice. extracting compiler (there can be many) include path can be an issue in some cases. or is there any simple way?
I'v tried with EXTERNAL_LIBC_INTERFACE and seems to work ok with jmp_buf size 14.

[seanshpark]

@ruben-ayrapetyan ,
I've made a patch: seanshpark@cef7eeb
This works with IoT.js but option is not exposed to Makefile. I'm not sure about the needs to other options and side effects it may cause so did not touch much. Can you review this?
And ... I can think of three options about this.

1. just merge as is and expand later when needed; simple
2. you can make what you were thinking and drop this(it's ok); depends on your time
3. you can guide me to expand this; may take some time

[ruben-ayrapetyan]

@seanshpark, could you, please, check #331?

The patch:

• adds USE_COMPILER_DEFAULT_LIBC option to CMakeLists.txt and Makefile: in case USE_COMPILER_DEFAULT_LIBC option is specified, USE_JERRY_LIBC flag is turned off;
• removes -nostdlib option in case USE_JERRY_LIBC mode is turned on;
• removes imported_libc target;
• turns off setup of LIBC_TARGET_NAME variable for case USE_JERRY_LIBC is turned off (in the case nostdlib is not specified, so compiler's default libc is linked).

extracting compiler (there can be many) include path can be an issue in some cases. or is there any simple way?

I agree with you that the include path extraction can be complex or inconvenient in some cases, so it is more reliable to introduce 'default compiler's libc' mode, as engine is, currently, compiled and linked using the same compiler.

[seanshpark]

Wonderful! #331 works perfect. Thank you very much!

[ruben-ayrapetyan]

@seanshpark, thank you!

[seanshpark]

close as #313 and #343 landed