Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support setjmp / longjmp in jerry-libc #194

Merged
merged 6 commits into from
Jun 17, 2015

Conversation

ruben-ayrapetyan
Copy link
Contributor

Commit pack contains the following:

  • implementation of setjmp / longjmp in jerry-libc for:
    • x86_64
    • x86_32
    • ARMv7 hardfp / softfp
  • switch of unit tests to jerry-libc (necessary for setjmp / longjmp unit test)
  • move of random number generator to jerry-libc (necessary for switching unit tests to jerry-libc)
  • fix of strncmp, fread and fwrite (fix of strncmp is necessary for switching unit tests to jerry-libc)

Related issue: #54

@egavrin
Copy link
Contributor

egavrin commented Jun 15, 2015

Could you please add support for ARMv7 softfp too? It'd be need soon.

@egavrin egavrin assigned ruben-ayrapetyan and unassigned egavrin Jun 16, 2015
@@ -28,6 +28,8 @@
#include "jrt.h"
#include "fdlibm-math.h"

#include <stdlib.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<stdlib.h> -> "jrt-libc-includes.h"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

@ruben-ayrapetyan
Copy link
Contributor Author

Could you please add support for ARMv7 softfp too? It'd be need soon.

Of course. I'll add.

@ruben-ayrapetyan ruben-ayrapetyan force-pushed the Ruben-support-setjmp-longjmp branch 2 times, most recently from 8ed30b1 to b92c943 Compare June 16, 2015 12:30
@ruben-ayrapetyan
Copy link
Contributor Author

@egavrin, I've added support for softfp.

@egavrin
Copy link
Contributor

egavrin commented Jun 16, 2015

Good to me.

\
svc #0; \
\
pop {r4-r12, pc};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Syscalls require to save all registers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't they? I would be grateful, if you would point to some accepted specification that describes system call-related requirements for saving register values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any documentation. But other libc implementations don't save them. The syscall implementation in the following link says: no registers are clobbered. I suspect the reason is avoid leaking information in registers for crackers.
https://chromium.googlesource.com/chromiumos/third_party/glibc-ports/+/factory-2460.B/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S

I also checked the SWI implementation in the kernel. It starts with saving registers r0-r12
http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S#L123

I seriously doubt that duplicating libc is a good idea. Systems with 1M ram does not run kernel, and we rely on their BSP. Systems with 16M ram has libc, and other applications (e.g. iot.js) will map it into the memory regardless of Jerry. So using libc is free from our perspective. Ultimately our duplicated libc just increase binary size. Maintenance is also difficult, and we cannot use optimizations (like register save skipping), because we want to be on the safe side. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and we cannot use optimizations (like register save skipping), because we want to be on the safe side.

In the case, we would oppose spending of several CPU cycles on each system call to possible reduce in code quality. As system call is relatively heavy operation, it seems to me that the optimization wouldn't somehow improve performance.

I seriously doubt that duplicating libc is a good idea. Systems with 1M ram does not run kernel, and we rely on their BSP. Systems with 16M ram has libc, and other applications (e.g. iot.js) will map it into the memory regardless of Jerry. So using libc is free from our perspective. Ultimately our duplicated libc just increase binary size. Maintenance is also difficult, and we cannot use optimizations (like register save skipping), because we want to be on the safe side. What do you think?

@zherczeg, thank you for sharing your view point. I think, it is better to continue the discussion in a 'discussion' issue, as it needs measurements and analysis for different platforms / configurations.

@zherczeg
Copy link
Member

What is the motivation of this work? Why don't we simply use the libc? We just duplicate existing code, and introduce high maintenance risk. Derivative works like iot.js obviously use libc.

@ruben-ayrapetyan
Copy link
Contributor Author

What is the motivation of this work?

Motivation of this work is to support setjmp / longjmp in currently used jerry-libc.

Why don't we simply use the libc? We just duplicate existing code, and introduce high maintenance risk. Derivative works like iot.js obviously use libc.

May be. For me it seems that the questions are out of scope of this pull request. Isn't it better to open a 'discussion' issue about them to list advantages / disadvantages of both approaches?

@ruben-ayrapetyan ruben-ayrapetyan assigned zherczeg and unassigned egavrin Jun 17, 2015
@zherczeg
Copy link
Member

lgtm

@egavrin
Copy link
Contributor

egavrin commented Jun 17, 2015

make push

…h folder.

JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
…the logic with call to rand in Math.random.

JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
…ARMv7 implementation to handle the softfloat-mode properly.

JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
@ruben-ayrapetyan ruben-ayrapetyan force-pushed the Ruben-support-setjmp-longjmp branch from b92c943 to de7b72d Compare June 17, 2015 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Feature implementation normal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants